ASN Gateway Overview

 

Access Service Network Gateway (ASN Gateway) is the subscriber-aware mobility access gateway for IEEE 802.16 mobile WiMAX radio access networks. These carrier- and enterprise-class platforms provide exceptional reliability and performance characteristics for mobile WiMAX operators.

The ASN Gateway provides inter-technology mobility for 3GPP, 3GPP2, DSL, and WiFi access technologies. This assures common billing and seamless inter-technology handover.

ASN Gateway is available for all chassis running StarOS Release 7.1 or later.

Important: The ASN Gateway is a licensed product that requires an Access Service Network Gateway support license.

ASN Gateway provides the following functionality, all of which is integrated with the chassis:

•	ASN Mobility Managment

•	DHCP proxy server

•	DHCP Relay

•	Connectivity Service Network (CSN) mobility

•	Intra-ASN and inter-ASN handover

•	Paging controller/location register

•	Radio resource controller relay function

•	Service Flow Authenticator (SFA)

•	Proxy-Mobile Internet Protocol (P-MIP) client

•	Mobile IP Foreign Agent (MIP FA) protocol

•	Data path function

•	Context server function

•	Handover relay function

•	WiMax NSP-ID functionality

•	802.1P QoS support

•	RADIUS-based prepaid accounting and hotlining for WiMAX

•	DHCP relay support for ASNGW

•	Creation, modification, and deletion of pre-provisioned/dynamic service flows

ASN Mobility Management

The Access Service Network Gateway (ASN Gateway) processes subscriber control and bearer data traffic. It also supports connection and mobility management across cell sites and inter-service provider network boundaries. An ASN Gateway is a logical entity in the Access Service Network (ASN) of a WiMAX radio access network and interfaces directly with base transceiver station or base station via an R6 GRE reference interface. An ASN Gateway performs control plane functions, bearer plane routing or bridging functions, resident functions in the connectivity service network, or a function in another ASN.

The ASN Gateway is placed at the edge of an ASN and is the link to the CSN. Each ASN Gateway can concentrate traffic from multiple radio base stations. This reduces the number of devices to manage and minimizes connection set-up latency by decreasing the number of call handovers in the network.

Basic ASN Gateway Network

To support Mobile IP and/or Proxy Mobile IP data applications, you can configure the system to perform the role of the ASN Gateway/foreign agent and/or the home agent within the connectivity service network (CSN) of your WiMAX data network. When functioning as a home agent, the system can be located within your WiMAX network or in the CSN of an external enterprise or ISP network. In either case, the ASN Gateway/foreign agent terminates the mobile subscriber’s call session and then routes the subscriber’s data to and from the appropriate home agent.

Basic ASN Gateway Mobile IP Network

EAP User Authentication

The ASN Gateway serves as the Extensible Authentication Protocol (EAP) authenticator and mobility key holder for subscriber connections and RADIUS clients to attached Authorization, Authentication, and Accounting (AAA) servers.

ASN Gateway and AAA

ASN control is handled by the ASN Gateway and the base station. The ASN Gateway control plane handles the feature set, including AAA functions, context management, profile management, service flow authorization, paging, radio resource management, and handover. The data plane feature set includes mapping radio bearer to the IP network, packet inspection, tunneling, admission control, policing, QoS, and data forwarding.

The ASN Gateway acts as an authenticator. It operates in pass-through mode for EAP authentication between the EAP client (the mobile station) and the EAP (AAA) server. After successful EAP authentication, the AAA server sends the master session key (MSK) to the ASN Gateway. The ASN Gateway, as authenticator, performs authorization key (AK) context management. It derives the AK from the MSK and sends it to the base station. As part of the AK context, other information, such as the AkID and CMAC are sent to the base station to secure the R1 interface.

An AAA module in the ASN Gateway provides flow information for accounting. Every detail about a flow, such as the transferred or received number of bits, the duration of the connection, and the applied policy, is retrievable from the data plane.

Profile Management

The ASN Gateway provides profile management and a policy function that resides in the connectivity network. Profile management identifies a subscriber’s feature set, such as the allowed QoS rate, number of flows, and type of flows.

In addition, the ASN Gateway maintains a context for the mobile subscriber and the base station. Each subscriber’s context contains the subscriber’s profile and security context, and the characteristics of the subscriber’s mobile device. The subscriber’s context is retrieved and exchanged between the serving base station and a target base station during handover.

The ASN Gateway authorizes service flows according to the subscriber’s profile. Allowed service flows and active service flows can change over time, so the ASN Gateway provides admission control for downlink traffic. The ASN Gateway creates a GRE tunnel per service flow.

Inter-ASN Handovers

During a handover, the ASN Gateway provides the subscriber’s context to a target base station and when requested, changes the data path. To minimize latency and packet loss, the ASN Gateway implements data integrity through bi-casting or multi-casting. For paging, buffering is also supported. A foreign agent maintains the IP connectivity if the mobile subscriber initiates an inter-ASN handover. The ASN Gateway supports either Proxy-Mobile IP (PMIP) or Client-Mobile IP (CMIP) in order to communicate with home agents.

The ASN Gateway maintains location information to provide the paging service that tracks subscribers when they are operating in idle mode. If there is any download traffic, ASN Gateway requests the PC to trigger paging. During active operation, location information is also updated as the mobile subscriber moves to a new base station.

Supported Features

The Access Service Network Gateway (ASN Gateway) provides ASN Gateway control and bearer plane routing functions:

•	BS Interface: R6 IP/GRE bearer plane

•	Inter-ASN handovers to other ASN Gateways: R4 IP/GRE bearer plane

•	Interactions with AAA management or policy servers: R3 RADIUS interface

•	Mobile IP Interface to HA in Connectivity Service Network: R3 IP-in-IP tunneling

A Profile C ASN Gateway is one of three alternative designs for radio resource management proposed by the WiMAX Forum. In Profile C architecture, the handover control component resides in the base stations. The ASN Gateway represents a transparent message relay point between neighboring base stations. The Radio Resource Controller (RRC) component in every BTS periodically polls its neighbors to build a resource availability database that it checks prior to triggering call handovers.

Profile C provides a high performance ASN Gateway platform with the following supported features in the current software version.

Important: Not all features are supported on all platforms.

Simple IPv4 Support

A Simple IP model supports non-mobile IP terminals and provides ASN-anchored mobility for fixed, nomadic, or portable mobility applications. A Simple IP architecture removes dependencies for separate foreign agent and home agent functions. ASN Gateway handles simultaneous combinations of Simple IP, Mobile IP, or Proxy Mobile IP calls. A Simple IP model permits the ASN to be combined or split from the CSN, depending upon the need for roaming. The Simple IP implementation includes a DHCP Proxy Server function for local or AAA-provided IP address assignment.

Simple IP provides a solution for stationary wireless DSL-like applications. It enables mobility on intra-ASN handovers between neighboring base stations and permits inter-ASN mobility via an R4 interface between ASN Gateways.

DHCP Proxy Server

Compared to 3G wireless technologies such as EV-DO (Evolution-Data Optimized) or PDP (Packet Data Protocol) Type PPP (Point-to-Point Protocol) contexts in General Packet Radio Service/Wideband Code division Multiple Access (GPRS/W-CDMA) networks, WiMAX networks do not use a PPP data link layer between access devices and the ASN Gateway. An alternative approach to IP address allocation is needed in Simple IP and Proxy Mobile IP usage models.

The ASN-GW includes a DHCP proxy/server/relay that interacts with the DHCP client function on the access device. In a Simple IP usage model, the DHCP server allocates dynamic addresses from a local address pool or fetches static addresses from subscriber profiles during authentication from a AAA server. Alternatively, the ASN-GW uses a DHCP relay process to forward the DHCP request to an external DHCP server.

In a Proxy Mobile IP use case, the ASN-GW uses a DHCP proxy to trigger a local foreign agent function to initiate a Mobile IP Request via the R3 interface to a home agent. The home agent returns the address via the Mobile IP Response. The DHCP Proxy component on the ASN Gateway conveys the address in a DHCP Response message to the DHCP client running on the user’s access device.

This solution enables mobility on intra-ASN handovers between neighboring base stations. It also permits inter-ASN mobility via an R4 interface between ASN Gateways.

DHCP Relay Support

Following are the enhancements and changes to the existing functionality of the DHCP relay. Refer to the DHCP Relay section for details.

•	DHCP Module enhancements, including the addition of DHCP Relay Agent option in the relayed messages to the DHCP server, DHCP Auth sub-option in the relayed messages to the DHCP server. and decoding of the DHCP Auth sub-option from the DHCP server messages

•	DHCP Relay for SIP and PMIPv4 calls

•	DHCP Relay support for Init reboot scenario

•	DHCP NAK is also handled through the DHCP Relay

•	AAA related enhancements, including receipt of the DHCP server address, DHCP-RK, DHCP-Key-ID attributes from the AAA, and decryption of the DHCP-RK

•	Session recovery support for SIP and PMIPv4 call lines with DHCP Relay functionality

•	CLI related enhancements, such as changes to subscriber configuration to enable the DHCP relay option, and configuration of DHCP Server Address, and DHCP-RK and DHCP-Key-ID in the DHCP service

ASN Gateway Micro-Mobility

ASN Gateway micro-mobility provides ASN Gateway-anchored L2 handovers. This low-latency procedure assures the seamless mobility of mobile access devices within a WiMAX network. The ASN Gateway supports both uncontrolled and controlled handovers for micro-mobility.

Uncontrolled Handovers

In an uncontrolled handover scenario, a mobile subscriber attempts to re-enter the WiMAX network at a target base station without the handover preparation procedures with the serving base station.

In order to authenticate the roaming user, the target base station obtains the subscriber and security context information from the serving ASN. The anchor authenticator ASN Gateway conveys the context response message and assists in the establishment of a new R6 GRE bearer connection to the target base station. It is referred to as an L2 operation because the previously assigned IP address for the binding remains the same on the anchor authenticator/data path ASN Gateway while the L2 BSID (Ethernet MAC address) is updated for the target base station.

Uncontrolled handovers are supported for both Simple IP or Mobile IP use cases.With uncontrolled L2 handover procedures, interactive and non-real-time applications incur minimal performance degradation and packet loss during subscriber movement between cell sites.

Controlled Handovers

A controlled handover occurs when a subscriber access device explicitly requests handover assistance from the serving base station to a new target base station. This process minimizes packet loss to the WiMAX access device. During the handover request, the serving base station provides the subscriber’s context information to the anchor authenticator ASN Gateway and a list of target base stations that are preferred by the mobile device. Upon a successful response from potential target base stations, the anchor authenticator ASN Gateway initiates a data path for the mobile subscriber to the target base station. It also transfers all contextual information for the session to the target base station. The downlink traffic for the mobile subscriber is simultaneously broadcast and subsequently buffered by each of the target base stations.

Controlled handovers may be triggered by the mobile access device or the serving base station as a congestion overload control mechanism.

Controlled handovers and associated data path pre-registrations minimize the impact on performance to a greater extent than uncontrolled handovers and significantly reduce datapath outages.

WiMAX R4 Inter-ASN Mobility Management

R4 inter-ASN mobility management procedures enable low latency call handovers between neighboring ASN Gateways located in different geographical regions or different operator networks. During mobility operations, the call is anchored on the anchor authenticator ASN Gateway. When a mobile subscriber roams to a destination cell site, the target base station connects to the anchor gateway over the serving ASN Gateway’s R4 interface. The R4 interface provides control functions such as security context transfers and IP/GRE bearer level connections. The data conveyed to the subscriber by the remote hosts is subsequently tunneled over R4 by the anchor authenticator gateway to the serving gateway. The current ASN Gateway implementation supports the co-existence of anchor authenticator and anchor datapath functions in the same ASN Gateway.

Supported R4 functionality includes:

•	R4 over Simple IP connections

•	R4 over Mobile IP connections

•	Anchor Gateway bi-casting over simultaneous R6 and R4 sessions

•	Co-location of DHCPv4 Proxy and PMIPv4 FA on anchor authenticator gateway

•	Support for multiple QoS service flows per-session via R4 tunnels

Important: Both the anchor gateway session and non-anchor gateway sessions are counted towards the session license separately. Licensed session limits are enforced based on the total number of anchor and non-anchor sessions.

WiMAX R3 CSN Anchored Mobility Management

The R3 reference point defines a set of control plane protocols between the Access Service Network (ASN) and Connectivity Service Network (CSN) to support AAA, policy enforcement, and mobility management functions. The R3 reference interface is used in a mobile IP application with the home agent acting as the call anchor point. In contrast to L2-based ASN anchored mobility procedures, CSN anchored mobility is L3-based and supports both proxy mobile IP and mobile IP calls. The R3 interface uses mobile IP signaling and IP-in-IP tunneling or GRE tunneling and includes standard features such as dynamic Home of Address (HoA) address allocation. Mobility signaling messages are authenticated by the home agent based on a dynamic user identity called a pseudo-NAI which changes after each authentication.

Mobile IP applications are well suited for inter-provider roaming applications and inter-technology handovers such as WiMAX-HRPD Rev A, WiMAX-WiFi, and WiMAX-W-CDMA. Mobile IP also provides an attractive solution for operators with a heterogeneous radio access network who want to support seamless mobility across base transfer stations from multiple RAN suppliers.

Important: Support for this function requires the HA feature license key.

Proxy Mobile IPv4 (PMIPv4)

The P-MIP procedure is designed only for Simple IP-capable access devices for which mobility procedures are performed entirely in the network. Certain events on the access device require relocation of the L3 anchor point (for example, CoA). One case is for the initial connection establishment in which the home agent or H-AAA server assigns an IP address and generates the mobility binding. Another is when the mobile subscriber roams across cell sites or ASNs and attaches to a target ASN Gateway.

Client Mobile IPv4 (CMIPv4)

CMIPv4 provides mobility procedures for mobile IP-capable access devices. In contrast to PMIPv4, where stateful DHCP proxy signaling triggers R3 signaling between the ASN Gateway and the home agent, CMIPv4 uses agent advertisement between the foreign agent component in the ASN Gateway and mobile IP client on subscriber access device. Mobile IP signaling occurs directly between the access device and the anchor foreign agent component in the ASN Gateway.

Authenticator

The authenticator function in the ASN Gateway acts as an anchored authenticator for a subscriber for the duration of the session. For example, as a subscriber moves between base stations served by the ASN Gateway, the authenticator anchor remains stationary. If a subscriber moves to a base station served by a different ASN Gateway, the anchor authenticator is hosted at that ASN Gateway. If the R4 interface is not supported between both gateways, only the subscriber needs to be re-authenticated.

The RADIUS client for authentication and accounting is collocated with the authenticator function. The ASN Gateway acts as an EAP relay and is agnostic to the EAP method. EAP transport between the ASN Gateway and the base station is performed as a control exchange. The base station functions as an EAP relay, converting Pair-wise Master Key version 2 (PKMv2) to the EAP messages for the ASN Gateway. The ASN Gateway works in pass-through mode and any EAP method that generates keys, such as MSK or EMSK, is supported in the system.

PKMv2 performs over-the-air user authentication. PKMv2 transfers EAP over the IEEE 802.16 air interface between the MS and the base station. The base station relays the EAP messages to the authenticator in the ASN Gateway. The AAA client on the authenticator encapsulates the EAP message in AAA protocol packets, and forwards them through one or more AAA proxies to the AAA server in the CSN of the home NSP. In roaming scenarios, one or more AAA brokers with AAA proxies may exist between the authenticator and the AAA server. AAA sessions always exist between the Authenticator and AAA server, with optional AAA brokers providing a conduit for NAI realm-based routing.

EAP Authentication Methods

WiMAX networks use Ethernet as the L2 protocol for network access authentication. The Extensible Authentication Protocol (EAP) provides the network authorization function. The ASN Gateway represents the EAP authenticator and supports a transparent relay point between the EAP client on the subscriber access device and EAP server on the AAA. The ASN Gateway triggers an EAP-identity request to the subscriber device. The subscriber device responds with an EAP-identity response. It subsequently unpacks EAP messages over the R6 interface and transfers them via RADIUS or Diameter signaling to the AAA server.

EAP authentication provide multiple authentication methods that can be tailored to the operator’s preference toward user-level, device-level, or user- and device-level network authorization. At the H-AAA server in Home Network Service Provider (H-NSP), device-level authentication in a roaming application guards against unauthorized network access by users with stolen access devices.

Supported RADIUS Methods

ASN Gateway supports following EAP authentication and authorization methods using RADIUS:

•	EAP-Pre-shared Key (EAP-PSK)

•	EAP-Transport Layer Security (EAP-TLS)

•	EAP-Tunneled Transport Layer Security (EAP-TTLS)

•	EAP-Authentication and Key Agreement (EAP-AKA)

EAP-Pre-shared Key (EAP-PSK)

EAP-PSK is a symmetric mutual authentication method that uses manually provisioned pre-shared keys between an EAP client on an access device and an EAP server component on AAA. The size of the pre-shared key can be up to 256 bytes.

EAP-Transport Layer Security (EAP-TLS)

EAP-TLS is an asymmetric authentication method that uses X.509 digital certificates, for example public/private key pairs, and enables device-based authentication.

EAP-Tunneled Transport Layer Security (EAP-TTLS)

EAP-TTLS is a multi-level authentication scheme to enable device and user-based authentication. The first level handshake provides device-level authentication and uses the same encryption and ciphering algorithms as EAP-TLS. The device can, but is not required to, be authenticated via a CA-signed PKI certificate to the server. The secure connection established through the first level handshake is then extended with MS-CHAP-V2 authentication to verify user credentials. As with other EAP methods, successful EAP transactions at AAA result in a Master Session Key (MSK) that is returned over an encrypted connection. The ASN Gateway uses the key to generate a derivative key for securing the air interface between ASN and user access device.

EAP-Authentication and Key Agreement (EAP-AKA)

EAP-AKA uses symmetric cryptography based on pre-shared private client/server keys and challenge-response mechanisms similar to other EAP methods. It verifies credentials for users of Removable User Identity Modules (R-UIMs).

Supported Diameter Methods

ASN Gateway supports the following Diameter methods for EAP authentication and authorization:

EAP-Authentication and Key Agreement (EAP-AKA)

EAP-AKA uses symmetric cryptography based on pre-shared private client/server keys and challenge-response mechanisms similar to other EAP methods. It verifies credentials for users of Removable User Identity Modules (R-UIMs).

WiMAX Prepaid Accounting

The system supports prepaid accounting for clients on the ASN Gateway.

Clients can communicate directly to a home AAA server or be proxied through a visited network’s AAA server. The following figure shows a typical prepaid network topology.

Prepaid Network Topology

Volume and Duration-based Prepaid Accounting

Prepaid accounting is a licensed-enabled feature. The ASN Gateway supports both volume threshold and duration threshold based prepaid accounting. Even though session-level accounting is performed for both volume and duration, the number of bytes in a multi-flow session is applied to a duration-based configuration.

RADIUS attributes identify thresholds and quotas for both volume (number of bytes) and duration (length of session).

Supported Enhanced Features

All enhanced features described in this section require the appropriate feature license keys.

Lawful Intercept

The Cisco Lawful Intercept feature is supported on the ASN Gateway. Lawful Intercept is a licensed-enabled, standards-based feature that provides telecommunications service providers with a mechanism to assist law enforcement agencies in monitoring suspicious individuals for potential illegal activity. For additional information and documentation on the Lawful Intercept feature, contact your local Cisco account representative.

Intelligent Traffic Control

Intelligent Traffic Control (ITC) supports customizable policy definitions. The policies enforce and manage service level agreements for a subscriber profile, thus enabling differentiated levels of services for native and roaming subscribers.

ITC includes features such as traffic prioritization, for example, marking DiffServ codepoints to enable unique treatments for the five WiMAX classes of service, queue redirection, and per-subscriber/per-flow traffic bandwidth control. Traffic policing enables maximum rate-based services and tiered bandwidth charging models. ITC includes a local policy engine that runs on an ASN Gateway in a Simple IP usage model, or as a home agent in a Mobile IP application. You can configure ITC policies statically with Class-Maps to identify applications flows that use L3/L4 5-tuple identifiers. You can then apply the resulting policy actions through policy maps and policy groups. The detection and programming of the local policy engine can alternatively be triggered on network access at the ASN Gateway as it retrieves QoS profiles for each authenticated user.

This feature provides a policy mechanism so you can enable user entitlements and provision treatments for native users and applications relative to roaming subscribers, Mobile Virtual Network Operators (MVNOs), and offnet P2P traffic.

Hotlining/Dynamic RADIUS Attributes

WiMAX is an all IP-based networking technology in which mobile operators seek a more profitable business model. One way to do this is to avoid traditional device subsidization that accompanies the sale of locked devices that restrict access to provisioned subscribers of an operator’s network. The WiMAX Forum has proposed remote Over-the-Air (OTA) activation protocols such as Open Mobile Alliance Device Management (OMA DM) to enable self-provisioned, self-configured, retail subscription models.

The ASN GW supports hotlining on a session basis. This capability is enabled by default. The rule-based hotlines use an IP redirection rule with the standard attribute Filter-ID. The server sends the ACL names in the Filter-ID attribute. This in turn, locates the rules.

Upon receiving a RADIUS Access-Accept message containing the Filter-ID attribute, the ASN GW locates the rule list, using the name contained in Filter-ID, and applies them to the session.

Configure the rules locally on the ASN GW under ACL groups.

In this scenario:

•	A user with an unprovisioned access device registers with a special decorated NAI that represents him/her as a non-subscriber to the AAA.

•	The AAA grants limited network access by returning a hotlining filter rule to the ASN Gateway. ASN GW hotlining support uses the standard attribute Filter-ID, along with the session identification parameters User-Name, Calling-Station-ID, and AAA-Session-ID.

•	An IP address is assigned during initial network entry. The ASN Gateway uses the redirect address associated with the filter rule to hotline the call to a web activation portal.

•	The user profile and subscription activation process is completed. The call is forwarded to the OMA DM server.

•	The OMA DM server triggers a network-initiated bootstrapping session with the OMA DM client on the user access device.

•	The OMA DM uses XML messaging over a secure OTA connection to remotely configure the access device.

•	If a session and an ACL list are located, the rules are applied to the session and a COA-ACK is returned. The AAA server transmits a RADIUS message to the ASN Gateway instructing it to “unhotline” the session.

•	At this point, the user is a known subscriber to the back-end subscription database and is granted unrestricted access to the network.

This feature facilitates a non-subsidized retail activation model through over-the-air user-driven subscription and remote device configuration. It also prevents unprovisioned users unrestricted access to the wireless operator’s network. This is a complementary technique you can use with operator fraud prevention systems by quarantining fraudulent user sessions or redirecting them to a billing/web portal.

Multi-flow QoS

Within a WiMAX ASN, QoS enforcement is administered by the Service Flow Authorization (SFA) component in the ASN Gateway (also referred to as Anchor Policy Charging Enforcement Function, or A-PCEF). SFA provides traffic management and QoS policy management for subscriber service flows.

Multi-flow QoS enables the establishment of static traffic policies for various subscriber application level service flows. It can be used in Simple IP or Mobile IP usage scenarios. The policies are stored in a Subscriber Policy Repository (SPR) database and retrieved as authenticated QoS profiles by the ASN Gateway. The A-PCEF negotiates via R6 with the Service Flow Manager (SFM) function on the base station. If the authorized QoS profile matches the available base station resources, the request is granted. The A-PCEF provides the following:

•	Traffic classification

•	Admission control

•	Prioritization (DSCP marking)

•	Per-session/per-flow bandwidth control

•	Flow mapping across application-specific R6/R4 GRE tunnels

In conjunction with multiflow QoS, the ASN Gateway offers configurable accounting on a per-session, per-R6, or per-service flow basis. Multi-flow QoS enables the OFDM radio access connection to be separated into multiple logical Connection ID’s (CIDs) with each pair of forward and reverse sub-channels transporting one or more application flows.

ASN Gateway supports pre-provisioned as well as dynamic service flows. A total of up to 12 uni-directional service flows per subscriber R6 or R4 session are possible.

Multi-flow QoS provides enhanced an user experience via end-to-end differentiated QoS connection-oriented services and stringent treatment for isochronous voice and delay-sensitive multimedia applications over broadband WiMAX networks. This feature also enables service convergence and is the foundation for delivery of IMS service control.

802.1P QoS Support

Quality of Service (QoS) is a method to better handle the challenges of reliability and quality despite increasing bandwidth demands. 802.1p which is a signaling technique for prioritizing network traffic at the data-link/MAC sublayer (OSI Reference Model Layer 2).

Network administrators have two major types of Quality of Service (QoS) techniques available. They can negotiate, reserve, and hard-set capacity for certain types of service, or simply prioritize data without reserving any capacity setting.

The 802.1p header includes a three-bit field for prioritization, which allows packets to be grouped into various traffic classes. The packets contain a 32-bit tag header located after a destination and source address header. IEEE 802.1p-compliant switches pick up this tag, read it, and put the packet in the appropriate priority queue. No bandwidth is reserved nor requested with this technique.

There are eight priority levels, numbered 0 throuh 7, and consequently, eight possible queues that can be created. Level 7 represents the highest priority and is assigned to mission-critical applications. Levels 6 and 5 are designed for delay-sensitive applications such as interactive video and voice. Levels 4 to 1 are suitable for regular enterprise data transfer, as well as streaming video. Level 0 is assigned to traffic that can tolerate a best-effort protocol.

For more information and configuration examples, see “ASN Gateway QoS and Service Flow Configuration” in this guide.

ASN Gateway Intra-Chassis Session Recovery

This feature enables the system to recover from single software or hardware faults without interrupting subscriber sessions or losing accounting information. Intra-chassis session recovery uses regular task check-pointing of active call states to insure that the fail-over task has the identical configuration and state as the failed process.

Session recovery is supported for the following major features:

•	Simple IP, Proxy Mobile IP or Client Mobile IP calls

•	R6 or R4 control signaling and bearer level subscriber traffic

•	Paging Controller/Location Register (PC/LR) idle mode sessions. PC/LR is a licensed-based feature.

•	L2TP LAC & LNS tunnels and sessions

Important: Minimum hardware requirements consist of four processing cards (3 Active, 1 Standby). When session recovery is enabled, overall system capacity may be reduced, depending upon configuration.

Intra-chassis session recovery provides hitless in-service recovery that increases system availability. This eliminates the need for the Radio Access Network to re-register large blocks of simultaneous users. It also minimizes the likelihood of revenue leakage due to the failure of network elements.

This feature requires a feature license key for ASN Gateway session recovery.

Robust Header Compression (ROHC)

Header compression is applied to ASNGW service flows when ROHC is enabled on the ASNGW and the MS and the AAA server authorize ROHC for the ASNGW call. ROHC parameter values are negotiated over R6. Unidirectional and bi-directional ROHC service flows are supported.

Supported Inline Services

All inline services described in this section require the appropriate feature license keys.

Enhanced Charging Service

The Enhanced Charging Service (ECS) is an in-line service feature integrated with the system. ECS provides flexible, differentiated, and detailed billing to subscribers by using Layer 3 through Layer 7 packet inspection. ECS can integrate with a back-end billing system. ECS functionality is supported at the point where sessions are anchored—for example, on the ASN Gateway for Simple IP sessions and on the home agent for Mobile IP sessions.

For more information about ECS, refer to the Enhanced Charging Services Administration Guide.

Multi-host Support

ASN Gateway’s multi-host feature provides multiple host connectivity.

A WiMAX CPE modem supports multiple IP hosts in fixed/nomadic applications. The modem shares a single WiMAX airlink to connect to the WiMAX IP network. This feature is an effective solution for small or home office users to provide multiple station connectivity through one airlink.

Multi Host Support in WiMAX Network

The WiMAX ASN Gateway allows each WiMAX MS (identified by its 6-byte MSID) to be assigned a single IP address. IP accounting is maintained for the IP address.

How it Works

The DHCP proxy server and the IP pool hosted locally on the ASN Gateway provide the primary IP address from a primary IP pool to the WiMAX customer premise equipment (CPE). The CPE is identified by its WiMAX R6 MSID (6-byte MAC address).

Important: Multiple IP hosts feature is not supported for Proxy-MIP session.

Once a primary IP address is assigned dynamically to the WiMAX CPE, additional IP addresses are assigned dynamically to other IP hosts. Each of the IP hosts is identified by its unique 6-byte MAC address. The DHCP proxy on the ASN Gateway manages the IP addresses by mapping them to the unique MAC addresses supplied by the client in the chaddr option field in DHCP DISCOVER or REQUEST messages.

The primary IP address is assigned to the CPE first via DHCP. It is followed by requests for additional IP addresses by individual IP hosts behind the CPE. The ASN Gateway allocates secondary hosts on-demand, up to the configured limit of 4.

Primary IP addresses assigned to WiMAX CPE and secondary IP addresses assigned to the IP hosts, are configured in separate IP pools or the same IP pool. Accounting is based on the primary IP address assigned to CPE and UDR accounting is enabled only for the primary session (flow/session based). No accounting is performed for secondary sub-sessions.

Using the device credentials of the WiMAX CPE, authentication is performed with the EAP-TLS method. There is no authentication for each assigned IP address, and no validation of MAC addresses contained in DHCP requests, except to make sure that they are unique across all subscribers connected to the DHCP proxy server.

IP Address Allocation through DHCP

The dynamic IP address allocation procedure for primary node and secondary hosts is described below:

•	After the initial network entry for WiMAX CPE is completed, the WiMAX CPE acts as a primary node and starts the DHCP process with the WiMAX ASN Gateway.

•	The DHCP proxy server hosted on the ASN Gateway allocates the Primary IP address to the WiMAX CPE as a primary node from the configured primary IP Pool.

•

The primary IP address is the first IP address assigned to the WiMAX CPE. The DHCP DISCOVER and REQUEST messages for this must contain the WiMAX R6 MSID as the chaddr field. After this IP address is assigned, the session goes into Connected state and is ready to accept DHCP requests for additional IP addresses for other IP hosts.

•	Once the primary IP address is assigned to the primary node (WiMAX CPE), hosts behind the CPE start the DHCP process with the WiMAX ASN Gateway for each host mapping to its 6-byte MAC address.

•	The DHCP proxy server hosted in the ASN Gateway allocates the secondary IP addresses to the hosts behind the CPE as an auxiliary node from the configured secondary IP Pool.

•

When session termination is requested, the primary IP address is the last IP address to be released by the clients and ASN Gateway. This means the primary IP address must be in use and in lease for the session to continue in Connected state. When the Primary IP address is released, the ASN Gateway session is terminated and all IP addresses are freed.

•	The auxiliary IP addresses can be assigned and freed any time during the call via DHCP messages.

ASN Gateway in a WiMAX Network

In a WiMAX network architecture, each of the entities, Subscriber Station (SS)/Mobile Station (MS), Access Service Network (ASN) and Connectivity Service Network (CSN) represent a grouping of functional entities.

Each of these functions may be in a single physical device or distributed over multiple physical devices to meet functional and interoperability requirements. The following figure shows a high-level example of WiMAX network architecture

WiMAX Network Architecture

Access Service Network (ASN)

The ASN is an aggregation of functional entities and corresponding message flows associated with the access services. The ASN represents a boundary for functional interoperability with WiMAX clients, WiMAX connectivity service functions, and other vendor-specific functions.

An ASN is defined as a complete set of network functions that provide radio access to a WiMAX subscriber. The ASN provides the following functions:

•	WiMAX Layer-2 (L2) connectivity with WiMAX SS/MS

•	The transfer of AAA messages to WiMAX subscribers’ Home Network Service Provider (H-NSP) for authentication, authorization, and session accounting for subscriber sessions

•	Network discovery and the selection of an appropriate NSP from which WiMAX subscribers accesses WiMAX service(s)

•	Relay functionality for establishing Layer-3 (L3) connectivity with a WiMAX SS/MS (IP address allocation)

•	Radio resource management

•	ASN-CSN tunneling

In addition to the above mandatory functions, for a portable and mobile environment the ASN supports the following functions:

•	ASN anchor mobility

•	CSN anchor mobility

•	Paging and location management

The ASN has the following network elements:

•

The WiMAX base station, which is a logical entity that embodies a full instance of the WiMAX Medium Access Control (MAC) layer and physical layer in compliance with the IEEE 802.16 suite of applicable standards. The base station may host one or more access functions and is logically connected to one or more ASN Gateways.

•	The ASN Gateway (ASN Gateway), which is a logical entity that represents an aggregation of control plane functional entities. These entities are paired with a corresponding function in the ASN, for example a base station instance, a resident function in the CSN, or a function in another ASN.

The ASN Gateway may also perform bearer plane routing or bridging functions.

The ASN consists of at least one instance of a base station and at least one instance of an ASN Gateway (ASN Gateway). An ASN may be shared by more than one Connectivity Service Networks (CSN).

The ASN decomposition with Network Reference Model (NRM) is shown in the following figure.

ASN Network Reference Model with ASN Gateway

Connectivity Service Network (CSN)

The Connectivity Service Network (CSN) is a set of network functions that provide IP connectivity services to the WiMAX subscriber. A CSN provides the following functions:

•	SS/MS IP address and endpoint parameter allocation for user sessions

•	Internet access

•	AAA proxy or server

•	Policy and admission control based on user subscription profiles

•	ASN-CSN tunneling support,

•	WiMAX subscriber billing and inter-operator settlement

•	Inter-CSN tunneling for roaming

•	Inter-ASN mobility

•	Home agent

The CSN also provides location-based services, connectivity for peer-to-peer services, provisioning, authorization and/or connectivity to IP multimedia services, and support for lawful intercept services in the WiMAX radio access network.

Important: CSN is out of the scope of this document.

WiMAX Reference Points and Interfaces

A reference point (RP) in a WiMAX network is a conceptual link. An RP connects two groups of functions that reside in different functional entities of an ASN, CSN, or mobile station (MS). It is not necessarily a physical interface; an RP becomes a physical interface only when the functional entities on either side of it are contained in different physical devices.

Following are the reference points implemented with the ASN Gateway for WiMAX mobility functions:

•

R3 Reference Point—Consists of the set of control plane protocols between the ASN and the CSN to support AAA, policy enforcement, and mobility management capabilities. It also encompasses the bearer plane methods (for example, tunneling) to transfer user data between the ASN and the CSN. R3 supports three types of clients: CMIPv4 (for MS/client capable of mobile IP), and PMIPv4 and PMIPv6 (proxy mobile IPv4 and IPv6, where ASNGW/FA proxy mobile IP supports MS/client) .

•	R4 Reference Point—Consists of the set of control and bearer plane protocols originating and terminating in various functional entities of an ASN that coordinate MS mobility between ASNs and ASN Gateways. R4 is the only interoperable RP between similar or heterogeneous ASNs.

•	R5 Reference Point—Consists of the set of control plane and bearer plane protocols for internetworking between the CSN operated by the home NSP and that operated by a visited NSP.

•

R6 Reference Point—Consists of the set of control and bearer plane protocols for communication between the base station and the ASN Gateway. The bearer plane is an intra-ASN datapath between the base station and ASN gateway. The control plane includes protocols for datapath establishment, modification, and release control, in accordance with the MS mobility events. R6, in combination with R4, may serve as a conduit for exchange of MAC state information between base stations that cannot interoperate over R8.

•

R7 Reference Point—Consists of an optional set of control plane protocols, for example, AAA and policy coordination in the ASN gateway as well as other protocols for coordination between the two groups of functions identified in R6. The decomposition of the ASN functions using the R7 protocols is optional.

Important: To provide high throughput and high density call processing, the ASN Gateway integrates both the Decision Point and Enforcement Point functions. Therefore, the R7 reference point is not exposed.

 

Message Relay in ASN

The ASN Gateway provides relay procedures to send or distribute received messages with responses from a base station or another ASN Gateway. Supported types of relay functions are:

•	Passive Relay: In this type of message relay, when the ASN Gateway receives a message on an R4 or R6 interface, it retrieves the destination ID and forwards the same request message to the given destination.

•

Active Relay: In this type of message relay, upon receiving the message on R4/R6 interface, the ASN Gateway creates a similar R4/R6 message on the basis of original message and relays it to the destination. For example, if during the inter-ASN Gateway handover a non-anchor ASN Gateway receives the data path registration request from the target base station, it creates a new data path registration request and sends it to the anchor ASN Gateway. After receiving the duplicate message, the anchor ASN Gateway sends the data path registration response to the non-anchor ASN Gateway. When it receives that message, the non-anchor ASN Gateway creates a new response message and sends the new data path registration response to the target base station.

ASN Gateway Architecture and Deployment Profiles

The ASN Gateway is part of the Access Service Network (ASN) within the WiMAX network. The ASN Gateway comprises logical and functional elements that provide different functionality in an ASN.

ASN profiles provide a framework for interoperability among entities within an ASN. At a high level, the WiMAX forum has defined groups of functionality for an ASN. These are called Profile Mappings A, B, and C. The key attributes of the profile mappings are:

•	ASN Profile-A

•	Handover control and Radio Resource control (RRC) in the ASN Gateway

•	ASN anchored mobility among base stations using R6 and R4 reference points

•	CSN anchored mobility among ASNs using PMIP/CMIP (R3)

•	Paging Controller and Location Register in the ASN Gateway

•	Profile-B: ASN Profile-B removes the ASN Gateway altogether and pushes all its functionality into the base station. This functionality includes the following:

•	Radio Resource control (RRC) handling within the base station

•	R3 reference point

•	R4 reference point

•	Profile-C: ASN Profile-C functionality is a subset of Profile-A with following functionality in Base Station:

•	HO control

•	Radio Resource Controller (RRC)

The ASN Gateway supports ASN Profile-C functionality. Form more information on supported features and functionality, refer to the Supported Feature section.

The following figure shows the mapping of functional entities in an ASN Gateway for Profile-C.

Functional view of ASN Gateway Profile-C

WiMAX Network Deployment Configurations

This section provides examples of how the system can be deployed within a WiMAX carrier’s network. As noted previously, the system can be deployed in standalone configurations, serving as an Access Service Network Gateway/Foreign Agent (ASN Gateway/FA), a Home Agent (HA), or in a combined ASN Gateway/FA/HA configuration which provides all services from a single chassis.

Standalone ASN Gateway/FA and HA Deployments

The ASN Gateway/foreign agent (FA) serves as an integral part of a WiMAX network by providing packet processing and re-direction to a mobile user’s home network through communications with the home agent (HA). No redirection is required when mobile users connect to an ASN Gateway that serves their home network.

The following figure shows an example of a network configuration in which the ASN Gateway/FA and HA are separate systems.

ASN Gateway/FA and HA Network Deployment Configuration Example

Co-Located Deployments

An advantage of the system is its ability to support both high-density ASN Gateway/FA and HA configurations within the same chassis. The economies of scale presented in this configuration example provide both improved session handling and reduced cost in deploying a WiMAX data network.

The following figure shows an example of a co-located deployment.

Co-located ASN Gateway/FA and HA Network Deployment Configuration Example

ASN Call Procedure Flows

This section provides information on the function of the ASN Gateway in a WiMAX network and presents call procedure flows for different stages of session setup.

 

Functional Components for Handover

This section describes the functional components used during handover between ASN Gateways on R4 and R6 interfaces.

Anchor ASN Gateway

The anchor ASN Gateway is the ASN Gateway that holds the anchor data path functions for a given MS. As shown in the following figure, the anchor ASN Gateway hosts the following functions:

•	Authenticator (includes Accounting Client)

•	Anchor DP function

•	DHCP proxy

•	DHCP Relay

•	PMIP client

•

MIP FA

•	Anchor SFA

•	DHCP proxy function

The ASN Gateway service IP address is the R6 and R4 tunnel endpoint and handles both R6 and R4 traffic.

Anchor Session

The following identifiers identify the anchor ASN Gateway session:

•

MSID

•

MS NAI

•	MS IP address

•	DHCP MAC address

The ASN Gateway session consists of an access R6 session and a MIP FA network session. The R6 session has a GRE data path to a base station for an active session. In this session the ASN Gateway service IP address is the R6 and R4 tunnel endpoint and handles both R6 and R4 traffic.

Upon initial network entry, when the DPF is in the anchor ASN Gateway, there is no R4 session. After a MS does a handover to a target BS, it connects to the anchor GW over R4 via a different serving ASN Gateway. At this point, the anchor GW session has an access R4 session and a MIP FA network session. The anchor GW can maintain the R6 session and a R4 session simultaneously.

Note that R6 and R4 tunnels are handled uniformly by the anchor GW as both are access-side tunnels. The anchor GW can check the IP address of the non-anchor GW peer against the configured list of peer ASN Gateway’s, so that it can control which R4 connections are accepted.

The anchor GW handles all the Layer 3 processing for the subscriber without including any other rule and policy.

When an anchor GW receives a request message, it reads the source ID in this request and sends the response to this source ID as destination ID. The anchor ASN Gateway remembers the source IP address of the peer from where the message was received, if it is different from the source ID of the message. The response message is sent to this peer IP address, which is the immediate peer.

Non-Anchor ASN Gateway

The non-anchor ASN Gateway hosts the following functions:

•	Serving DP Function: The subscriber data is not processed in the non-anchor GW. It relays the subscriber data to anchor ASN Gateway over R4. When the inner IP packet emerges from the R6 tunnel at the non-anchor ASN Gateway, the packet is sent over R4 data path tunnel to the Anchor ASN Gateway.

•	Serving SFA Function: No packet classification is performed in this function. It provides only tunnel switching between R4 to R6 or vice versa.

•

DHCP Proxy relay Function: DHCP messages are not processed in the non-anchor GW and relayed to the DHCP proxy in the anchor ASN Gateway over R4. When the inner IP packet emerges from the R6 tunnel at the non-anchor ASN Gateway, a check is made to see whether the DHCP proxy is co-located in the ASN Gateway and whether or not to process DHCP packet locally. If the session is not anchored locally, that is, the DHCP proxy is not co-located, the non-anchor ASN Gateway sends the DHCP packet over an R4 data path tunnel to the anchor ASN Gateway.

•	Relay Function: The non-anchor ASN Gateway provides relay functions to distribute received messages and subscriber information. The message relay is supported for following functions:

•	Context transfer

•

Paging

•	Accounting

•	Authentication

•	Handover (HO)

•	Radio Resource Controller (RRC)

Non-Anchor Session

A non-anchor session is created upon receiving an R6 Data Path Registration Request from the target base station. Note that the non-anchor ASN Gateway session is identified by MSID only. This non-anchor ASN Gateway does NOT know the MS NAI and MS IP address of the subscriber, since the authenticator, DHCP and PMIP functions are not exposed here and the MSID is used as the username in session manager. The non-anchor session has the following attributes:

•	The Registration Type in the request is set to HO.

•	The Destination ID in the message does not match the destination IP address of the message. It needs to match the anchor ASN Gateway ID in the message if an R6 and R4 Data Path setup is intended.

•	The anchor ASN Gateway is one of the peer ASN Gateway configured in the ASN Gateway service.

Initial Network Entry and Data Path Establishment without Authentication

This section describes the procedure of initial entry and data session establishment for a WiMAX subscriber station (SS) or MS without authentication by ASN Gateway.

Initial Network Entry and Data Session Establishment without Authentication Call Flow

Initial Network Entry and Data Session Establishment without Authentication Call Flow Description

Step	Description
1	MS performs initial ranging with the ASN BS. Ranging is a process by which an MS becomes time-aligned with the ASN BS. The MS is synchronized with the BS at the successful completion of ranging and is ready to set up a connection.
2	MS sends basic capability exchange request (SBC-REQ) to ASN BS.
3	ASN BS sends MS-Pre-Attachment Request (authorization policy request) to ASN Gateway.
4	ASN Gateway sends MS-Pre-Attachment Response on the basis of authorization policy to ASN BS for MS.
5	ASN BS sends basic capability exchange response (SBC-RSP) to MS.
6	If authorization policy allows, ASN BS sends MS Pre-Attachment Acknowledgement to ASN Gateway.
7	MS sends Registration-Request (REG-REQ) to ASN BS.
8	ASN BS sends MS-Attachment-Request to ASN Gateway.
9	ASN Gateway sends MS-Attachment-Response to ASN BS and reserves the resource.
10	ASN BS sends Registration-Response to MS.
11	ASN BS sends MS-Attachment-Acknowledgement to ASN Gateway.
12	ASN Gateway sends Path Registration Request to ASN BS.
13	ASN BS creates 802.16 connection and establishes path with MS.
14	ASN BS sends Path Registration Response to ASN Gateway and ASN Gateway creates service flow with CSN over which PDUs can be sent and received.
15	ASN Gateway sends Path Registration Acknowledgment to ASN BS.
16	GRE tunnel mapped to 802.16 connection between MS and ASN BS.
17	R6 GRE data path established between ASN BS and ASN Gateway and data flow starts.

‌

Initial Network Entry and Data Path Establishment with Authentication (Single EAP)

This section describes the procedure of initial entry and data session establishment for a WiMAX Subscriber Station (SS) or MS with single EAP authentication.

The following figure provides a high-level view of the steps involved for initial network entry of an SS/MS with EAP authentication and data link establishment. The following table explains each step in detail.

Initial Network Entry and Data Session Establishment with Authentication Call Flow

Initial Network Entry and Data Session Establishment with Authentication Call Flow Description

Step	Description
1	MS performs initial ranging with the BS. Ranging is a process by which an MS becomes time aligned with the BS. The MS is synchronized with the BS at the successful completion of ranging and is ready to set up a connection.
2	SS Basic capability exchange (SBC-REQ) between MS and BS starts and MS-Info-Request for authorization policy sent to AAA client/authenticator in ASN Gateway.
3	AAA client/authenticator (ASN Gateway) sends MS-Info-Report to BS and BS sends SS Basic Capability Response (SBC-RSP) to MS.
4	BS acknowledges the MS-Info-Report to AAA client/authenticator.
5	AAA client/authenticator (ASN Gateway) starts EAP transfer request to BS and MS.
6	MS and BS sends EAP transfer response to AAA client/authenticator.
7	The MS progresses to an authentication phase with home AAA Server. Authentication is based on PKMv2 as defined in the IEEE standard 802.16 specification. EAP authentication process starts
8	EAP authentication successful and AAA client/authenticator starts security context transfer.
9	PKMv.2-RSP/EAP-Transfer/SA-TEK-Challenge-Request-Response/Key-Request-Response exchange between MS and BS.
10	MS sends 802.16 Registration Request (REG-REQ) to ASN BS and ASN BS sends MS-Info-Request to AAA client/authenticator.
11	AAA client/authenticator sends MS-Info-Report to BS and BS sends Registration Response (REG-RESP) to MS and MS-Info-Report Acknowledge to AAA client/authenticator.
12	ASN Gateway sends Path Registration Request to ASN BS.
13	ASN BS creates 802.16e connection and establishes path with MS.
14	ASN BS sends Path Registration Response to ASN Gateway and ASN Gateway creates service flow with CSN over which PDUs can be sent and received.
15	ASN Gateway sends Path Registration Acknowledgment to ASN BS.
16	GRE tunnel mapped to 802.16 connection between MS and ASN BS.
17	R6 GRE data path established between ASN BS and ASN Gateway and data flow starts.

‌

Unexpected Network Re-entry

An unexpected network re-entry is when a mobile station starts the process of initial network entry to the ASN Gateway via the same or new base station while an existing call for the MS is still in progress or being set up. When this occurs, the ASN Gateway’s default behavior is to:

•	Accept the new call regardless of the existing call state if the pre-attachment request of the new call comes from a different BS.

•	Accept the new call if the original call is in any state past the pre-attachment phase and the pre-attachment request of the new call comes from the same BS.

•	Drop the original call in favor of new call.

To disable this default behavior use the policy ms-unexpected-network-reentry command in the ASN Gateway Service Configuration Mode. For more information regarding this command, refer to the Command Line Interface Reference.

MS Triggered Network Exit

This section describes the procedure of MS Triggered network exit for a WiMAX Subscriber Station (SS) or MS in normal mode.

The following figure provides a high-level view of the steps involved for network exit of an SS/MS in normal mode. The following table explains each step in detail.

MS Triggered Network Exit Call Flow

MS Triggered Network Exit Call Flow Description

Step	Description
1	MS sends DREG_REQ message to ASN BS in serving ASN, including De-Registration_Request Code=0x00.
2	ASN BS sends R6 Path_Dereg_Req message to ASN Gateway.
3	ASN Gateway/FA and HA starts MIP release procedure.
4	ASN Gateway/FA starts MS context delete procedure.
5	ASN Gateway sends Accounting-Stop-Request (Release Indication) message to AAA.
6	AAA replies with Accounting-Stop-Response message to ASN Gateway.
7	ASN Gateway/FA replies with Path_Dereg_Response message to ASN BS.
8	ASN BS sends DREG_CMD message to MS, including Action Code=0x04.
9	ASN BS sends R6 Path_Dereg_Ack to the ASN Gateway and related entities releases the retained MS context and the assigned data path resource for the MS.

‌

Network Triggered Network Exit

This section describes the procedure of a network triggered network exit for a WiMAX Subscriber Station (SS) or MS in normal mode.

The following figure provides a high-level view of the steps involved for a network-triggered network exit of an SS/MS in normal mode. The following table explains each step in detail.

Network Triggered Network Exit Call Flow

Network Triggered Network Exit Call Flow Description

Step	Description
1	Network entities, such as AAA Server, ASN Gateway FA/HA, trigger Session Release Trigger to ASN BS. This can be from H-AAA ServerAnchor ASN Gateway/FA/HAServing ASN BS, etc.
2	ASN BS sends DREG_CMD message to MS, including Action Code=0x00 to indicate MS existing network.
3	IP session for DHCP/MIP release starts between MS and network entities.
4	MS sends DREG_REQ to ASN BS with De-Registration_Request_Code=0x02.
5	ASN BS sends Path_Dereg_Req message to ASN Gateway.
6	Auth Context Request and Report Exchange between target BS and ASNGW.
7	ASN Gateway/FA and HA starts MIP release procedure.
8	ASN Gateway/FA exchanges NetExit_MS_State_Change_Req and NetExit_MS_State_Change_Rsp messages with the anchor accounting client, anchor authenticator, and MIP client to delete MS contexts.
9	ASN Gateway sends Accounting-Stop-Request (Release Indication) message to H-AAA.
10	AAA replies with Accounting-Stop-Response message to ASN Gateway.
11	ASN Gateway/FA replies with Path_Dereg_Response message to ASN BS.
12	HO Complete message sent from target BS to serving BA via ASNGW.
13	ASN BS sends R6 Path_Dereg_Ack to the ASN Gateway and related entities releases the retained MS context and the assigned data path resource for the MS.

‌

Intra-ASN Gateway Handover

This section describes the handover procedure between two ASN BSs connected to one ASN Gateway. The ASN Gateway supports following types of handover:

•	Intra-anchor ASN Gateway Uncontrolled Handover

•	Intra Non-anchor ASN Gateway Uncontrolled Handover

•	Intra-anchor ASN Gateway Controlled Handover

•	Intra Non-anchor ASN Gateway Controlled Handover

Details regarding controlled and uncontrolled handovers for the anchor ASN gateways are provided below.

Intra-anchor ASN Gateway Uncontrolled Handover

This section describes the procedure for an uncontrolled intra-anchor ASN Gateway handover for a WiMAX Subscriber MS.

The following figure provides a high-level view of the steps involved in an intra-anchor ASN Gateway uncontrolled handover of an SS/MS. The following table explains each step in detail.

Intra-ASN Gateway Uncontrolled Handover Call Flow

Intra-ASN Gateway Uncontrolled Handover Call Flow Description

Step	Description
1	MS sends RNG-REQ message to target ASN BS.
2	Target ASN BS sends Context-Request message to anchor ASN Gateway for this MS.
3	Anchor ASN Gateway forwards Context-Request message to serving ASN BS.
4	Serving ASN BS sends Context-Report message with MS context information to anchor ASN Gateway.
5	Anchor ASN Gateway forwards Context-Report message with MS context information to target ASN BS.
6	Target ASN BS sends Path Registration Request to anchor ASN Gateway.
7	Anchor ASN Gateway replies with Path Registration Response to target ANS BS.
8	Target ANS BS sends ranging response with RNG_RSP message to MS.
9	Target ASN BS sends Path Registration Acknowledge to anchor ASN Gateway.
10	R6 GRE data path established between target ASN BS and anchor ASN Gateway and data flow starts.
11	Target ASN BS sends CMAC Key Count Update message to anchor ASN Gateway.
12	Anchor ASN Gateway replies with CMAC Key Count Update ACK message to target ASN BS.
13	Anchor ASN Gateway sends Path_De-Reg_Req message to release data path to serving BS.
14	Serving ASN BS sends Path_De-Reg_Rsp message to anchor ASN Gateway.
15	R6 GRE data path terminated between serving ASN BS and anchor ASN Gateway.

‌

Intra-anchor ASN Gateway Controlled Handover

An intra-anchor ASN Gateway controlled handover consists of the following types and phases.

MS Initiated Intra-anchor ASN Gateway Controlled Handover

This section describes the intra-anchor ASN Gateway controlled handover between two base stations initiated by a mobile station.

HO Preparation Phase

This is the initial phase for a controlled handover between two BSs.

The following figure and table describe the call flow for the steps involved in a controlled intra-ASN Gateway handover preparation phase between two BSs.

MS initiated Controlled Intra-ASN Gateway Handover Preparation Phase

MS initiated Controlled Intra-ASN Gateway Handover Preparation Phase Description

Step	Description
1	MS sends MOB_MSHO_REQ messages to serving BS
2	Upon receiving MS initiated handover request (MOB_MSHO_REQ), the serving BS sends HO_Req messages to target BS selected by MS and starts R8_HO_Req timer
3	Targeted BS tests the acceptability of the requested HO by comparing the amount of available resources and required bandwidth/QoS parameters in the HO request received from serving BS
4	Once a target BS accepts the request it sends the HO_Rsp message to the serving BS
5	Serving BS sends MOB_MSHO_RSP response t o MS
6	Serving BS sends HO_Ack message to the target BS and HO preparation phase is completed

‌

HO Action Phase

The following figure and table describe the call flow for the steps involved in uncontrolled intra-ASN Gateway handover action phase between two BSs.

MS initiated Controlled Intra-ASN Gateway Handover Action Phase

MS initiated Controlled Intra-ASN GW Handover Phase

Step	Description
1	Once HO preparation phase is completed and target BS receives HO-Ack message, the MS sends MOB_HO-IND messages to the serving BS.
2	The serving BS sends HO_Conf messages to the selected target BS with other context information and starts R8_HO_Confirm Timer.
3	The target BS accepts the request and sends the HO_Ack message to serving BS and serving BS stops R8_HO_Confirm Timer.
4	Target BS sends MAC Context Request message to the anchor ASN Gateway.
5	The anchor ASN Gateway forwards the MAC Context Request to the serving BS.
6	Serving BS sends MAC Context Report information to anchor ASN Gateway.
7	Anchor ASN Gateway forwards MAC Context Report information to the target BS.
8	Target BS sends Authentication Context Request to anchor ASN Gateway.
9	Anchor ASN Gateway transfers Authentication Context information to target BS.
10	MS starts ranging with target BS and sends RNG-REQ to the target BS and network reentry completed.
11	Target BS sends Data Path Registration Request to anchor ASN Gateway.
12	Anchor ASN Gateway sends Data Path Registration Response to target BS.
13	Target BS sends Data Path Registration Ack message to Anchor ASN Gateway and R6 data path is established.
14	Target BS sends CMAC Key count Update message to anchor ASN Gateway.
15	Anchor ASN Gateway sends CMAC Key Count Update Ack message to target BS and handover completed.
16	Anchor AS NGW starts Data Path De-registration process with serving BS.
17	Serving BS releases all resources and terminates data path with MS.

‌

BS Initiated Intra Anchor ASN Gateway Controlled Handover

This section describes the intra-anchor ASN Gateway controlled handover between two base stations initiated by serving base station.

HO Preparation Phase

This is the initial phase for a controlled handover between two BSs.

The following figure and table describe the call flow for the steps involved in uncontrolled intra-ASN Gateway handover preparation phase between two BSs.

BS initiated Controlled Intra-ASN Gateway Handover Preparation Phase

BS initiated Controlled Intra-ASN Gateway Handover Preparation Phase Description

Step	Description
1	In BS initiated HO scenario, the serving BS sends HO_Req messages to target BS from its peer list and starts R8_HO_Req timer.
2	Targeted BS tests the acceptability of the requested HO by comparing the amount of available resources and required bandwidth/QoS parameters in the HO request received from serving BS.
3	Once a target BS accepts the request it sends the HO_Rsp message to the serving BS.
4	Serving BS sends MOB_MSHO_RSP response t o MS.
5	Serving BS sends HO_Ack message to the target BS and HO preparation phase is completed.

‌

HO Action Phase

The following figure and table describe the call flow for the steps involved in an uncontrolled intra-ASN Gateway handover action phase between two BSs.

BS initiated Controlled Intra-ASN Gateway Handover Action Phase

BS initiated Controlled Intra-ASN Gateway Handover Action Phase Description

Step	Description
1	Handover preparation phase is completed and data path is established.
2	The serving BS sends HO_Conf messages to the selected target BS with other context information and starts R8_HO_Confirm Timer.
3	The target BS accepts the request and sends the HO_Ack message to serving BS and serving BS stops R8_HO_Confirm Timer.
4	Target BS sends MAC Context Request message to the anchor ASN Gateway.
5	The Anchor ASN Gateway forwards the MAC Context Request to the serving BS.
6	Serving BS sends MAC Context Report information to anchor ASN Gateway.
7	Anchor ASN Gateway forwards MAC Context Report information to the target BS.
8	Target BS sends Authentication Context Request to anchor ASN Gateway.
9	Anchor ASN Gateway transfers Authentication Context information to target BS.
10	MS starts ranging with target BS and sends RNG-REQ to the target BS and network reentry completed.
11	Target BS sends Data Path Registration Request to anchor ASN Gateway.
12	Anchor ASN Gateway sends Data Path Registration Response to target BS.
13	Target BS sends Data Path Registration Ack message to anchor ASN Gateway and R6 data path established.
14	Target BS sends CMAC Key count Update message to anchor ASN Gateway.
15	Anchor ASN Gateway sends CMAC Key Count Update Ack message to target BS and handover completed.
16	Anchor AS NGW starts Data Path De-registration process with serving BS.
17	Serving BS releases all resources and terminates data path with MS.

‌

Inter-ASN Gateway Handover

This section describes the procedure of inter-ASN Gateway handovers through an R4 interface for a WiMAX Subscriber Station (SS). The R4 reference is the interface over which ASN control and data messages are exchanged between two ASN Gateways, either within the same ASN or across separate ASNs.

For a given subscriber, a WiMAX session may be handled by ASN Gateway functions located in different physical nodes in the network. For example, the authenticator and FA may be located in ASN Gateway x and the R6 Data Path Function in ASN Gateway y. The various ASN Gateway functions communicate over the R4 interface.

The following inter-ASN Gateway handover scenarios are supported on the ASN Gateway over the R4 interface:

Important: Not all features are supported on all platforms.

•	Controlled Anchor ASN Gateway to Non-Anchor ASN Gateway Handover

•	Controlled Non-Anchor ASN Gateway to Anchor ASN Gateway Handover

•	Controlled Non-Anchor ASN Gateway to Non-Anchor ASN Gateway Handover

•	Uncontrolled Anchor ASN Gateway to Non-Anchor ASN Gateway Handover

•	Uncontrolled Non-Anchor ASN Gateway to Anchor ASN Gateway Handover

•	Uncontrolled Non-Anchor ASN Gateway to Non-Anchor ASN Gateway Handover

ASN Gateway Function for Handovers

An ASN Gateway configured for inter-ASN Gateway handovers requires the following functionality to support the handover via an R4 interface.

The following figure provides a high-level view of the components and functions distribution in ASN Gateway.

Distribution of Components and Function in ASN Gateway for Handover

Controlled Anchor ASN Gateway to Non-Anchor ASN Gateway Handover

For Controlled handovers, the ASN Gateway provides and/or supports the following functions:

•

Message Relay: The ASN Gateway provides the passive relay function for HO Request, HO Response, HO Ack, HO Confirm, and HO Complete messages in a stateless fashion. The gateway keeps the statistics of the different types of messages it has relayed. Retransmission of these messages is handled by the BS.

The serving BS generates these messages. The serving BS generates a different HO Request transaction for each target BS. In other words, the gateway does not generate multiple HO Request messages after receiving a single HO Request message with multiple target BSs. Generally, the HO transaction is initiated by the serving BS which also chooses the selected target BS to which the handover will take place.

•	Security Context Retrieval: The ASN Gateway supports the retrieval of the security context using Context Request and Context Report messages. This retrieval is also stateless. The context retrieval operation can be performed at any time during the lifetime of a call.

•	Data Path Registration: After Pre-Registration, the target BS performs Data Path Registration. Data Path Registration is performed using a 3-way handshake. If Pre-Registration has occurred, the Data Path Registration messages do not contain any service flow information.

•	If Pre-Registration has not occurred, the Data Path Registration messages carry the service flow information.

•	Data Path Pre-Registration and Data Path Registration is initiated by the BS.

Preparation Phase

The following figure and table provides a high-level view of the steps involved during the preparation phase of a controlled inter-ASN Gateway handover of an SS/MS from an anchored gateway to a non-anchored gateway.

Controlled Inter-ASN Gateway Handover Procedure - Preparation Phase

Controlled Inter-ASN Gateway Handover Procedure - Preparation Phase Description

Step	Description
1	MS sends a MOB_MSHO-REQ message to the serving ASN BS.
2	Serving ASN BS sends a Handover Request message to the target ASN BS.
3	Target ASN BS sends a Context-Request message to the target non-anchor ASN Gateway for this MS.
4	Target non-anchor ASN Gateway forwards the Context-Request message to the anchor ASN Gateway.
5	Anchor ASN Gateway sends a Context-Report message to the target non-anchor ASN Gateway.
6	Target non-anchor ASN Gateway forwards the Context-Report message to the target ASN BS.
7	Target ASN BS sends a Path Pre-Registration Request message to the target non-anchor ASN Gateway. Pre-registration is optional.
8	Target non-anchor ASN Gateway forwards the Path Pre-Registration Request message to the anchor ASN Gateway. Pre-registration is optional.
9	Anchor ASN Gateway sends a Path Pre-Registration Response message to the target non-anchor ANS GW. Pre-registration is optional.
10	Target non-anchor ASN Gateway forwards the Path Pre-Registration Response message to the target ASN BS. Pre-registration is optional.
11	Target ASN BS sends a Path Pre-Registration Acknowledge message to the target non-anchor ASN Gateway. Pre-registration is optional.
12	Target non-anchor ASN Gateway forwards the Path Pre-Registration Acknowledge message to the anchor ASN Gateway. Pre-registration is optional.
13	Target BS sends a Handover Response message to the serving BS.
14	Serving BS sends a MOB_BSHO-RSP message to the MS.
15	Serving BS sends a Handover Acknowledge message to the target BS.

‌

Action Phase

The following figure and table provides a high-level view of the steps involved during the action phase of a controlled inter-ASN Gateway handover of an SS/MS from an anchored gateway to a non-anchored gateway.

Controlled Inter-ASN Gateway Handover Procedure - Action Phase

Controlled Inter-ASN Gateway Handover Procedure - Action Phase Description

Step	Description
1	MS sends a MOB_MSHO-IND message to the serving ASN BS.
2	Serving ASN BS sends a Handover Confirm message to the target ASN BS.
3	Target ASN BS sends a Handover Acknowledge message to the serving ASN BS.
4	MS moves off of the serving ASN Gateway and re-enters the network through target ASN BS.
5	Target ASN BS sends a Path Registration Request message to the target non-anchor ASN Gateway.
6	Target non-anchor ASN Gateway forwards the Path Registration Request message to the anchor ASN Gateway.
7	Anchor ASN Gateway sends a Path Registration Response message to the target non-anchor ANS GW.
8	Target non-anchor ASN Gateway forwards the Path Registration Response message to the target ASN BS.
9	Target ASN BS sends a Path Registration Acknowledge message to the target non-anchor ASN Gateway.
10	Target non-anchor ASN Gateway forwards the Path Registration Acknowledge message to the anchor ASN Gateway.
11	Target non-anchor ASN Gateway sends/receives CMAC Key Count Update and Acknowledge messages to/from anchor ASN Gateway.
12	Target ASN BS sends a Handover Complete message to the serving ASN BS.
13	Anchor ASN Gateway sends/receives Path De-Reg Req/Rsp/Ack messages (to release the data path) to/from Serving BS.
14	R6 GRE data path terminated between Serving ASN BS and Anchor ASN Gateway.

‌

Uncontrolled Anchor ASN Gateway to Non-Anchor ASN Gateway Handover

The following figure and table provides a high-level view of the steps involved in an uncontrolled inter-ASN Gateway handover of an SS/MS from an anchored gateway to a non-anchored gateway.

Uncontrolled Inter-ASN Gateway Handover Procedure

Uncontrolled Inter-ASN Gateway Handover Procedure Description

Step	Description
1	MS sends RNG-REQ message to target ASN BS.
2	Target ASN BS sends Context-Request message to serving ASN BS.
3	Serving ASN BS sends Context-Report message with MS context information to target ASN BS.
4	Target ASN BS sends Context-Request message to target non-anchor ASN Gateway.
5	Target non-anchor ASN Gateway forwards Context-Request message to anchor ASN Gateway.
6	Anchor ASN Gateway sends Context-Report message with MS context information to target non-anchor ASN Gateway.
7	Target non-anchor ASN Gateway forwards Context-Report message to target ASN BS.
8	Target ASN BS sends Path Registration Request to target non-anchor ASN Gateway.
9	Target non-anchor ASN Gateway forwards Path Registration Request to anchor ASN Gateway.
10	Anchor ASN Gateway replies with Path Registration Response to target non-anchor ANS GW.
11	Target non-anchor ASN Gateway forwards Path Registration Response to target ASN BS.
12	Target ANS BS sends ranging response with RNG_RSP message to MS.
13	Target ASN BS sends Path Registration Acknowledge to target non-anchor ASN Gateway.
14	Target non-anchor ASN Gateway forwards Path Registration Acknowledge to anchor ASN Gateway.
15	R6 GRE data path established between Target ASN BS and anchor ASN Gateway. Data flow starts.
16	Target ASN BS sends/receives CMAC Key Count Update and Acknowledge messages to/from anchor ASN Gateway via target non-anchor ASN Gateway.
17	Anchor ASN Gateway sends/receives Path De-Reg Req/Rsp/Ack messages to release data path to/from serving BS.
18	R6 GRE data path terminated between Serving ASN BS and anchor ASN Gateway.

‌

RADIUS-based Prepaid Accounting for WiMax

Online accounting is set up by the exchange of RADIUS Access-Request and Access-Accept packets. The initial Access-Request packet from the ASN GW and/or the home agent includes a prepaid accounting capability (PPAC) vendor specific attribute too the prepaid server (PPS). This indicates support for online accounting at the ASN and/or the home agent. If the subscriber’s session requires online charging, the PPS assigns a prepaid accounting quota (PPAQ) to the PPC with RADIUS Access-Accept packets. As the session continues, the PPC and the PPS replenish the quotas by exchanging RADIUS packets.

Note the following:

•	ASN GW operates as the prepaid client (PPC).

•	In the case of a mobile IP call, both the ASN GW and the home agent work independently as the prepaid client. Both the ASN GW and the home agent send online access requests to the configured RADIUS servers independently.

•	Only session-based online accounting is supported.

Obtaining More Quota after the Quota is Reached

The following figure and table provide a high-level view of the steps involved in allocating additional quotas for prepaid calls once the original quota is reached.

Call Flow Showing How Additional Quota is Obtained

Call Flow Showing How Additional Quota is Obtained

Step	Description
1	During network entry, a NAS sends an Access-Request packet to the HCSN. If the NAS supports a PPC, the NAS includes the PPAC attributes, indicating it prepaid capabilities.
2	If the subscriber session is a prepaid session, the PPS (HAAA) assigns the initial prepaid quota(s) by including one or more PPAQ attributes in the Access-Accept packet.
3	Once the threshold for the quota(s) is reached, the PPC sends an Authorize-Only Access-Request to request additional quota. The request contains one or more PPAQs that indicate which quota(s) need to be replenished to the PPS.
4	The PPS responds with an Access-Accept packet that contains one or more replenished quotas.
5	Once again, a threshold is reached for one or more of the quotas. The PPC sends an Authorize-Only Access-Request to the PPS to request more quota.
6	The PPS responds with the final quota in an Access-Accept. The final quota is indicated by the presence of the Terminate-Action subtype. The Terminate-Action subtype includes the action for the PPC to take once the quota is reached.
7	The quota expires. The PPC sends an Authorize-Only Access-Request packet to indicate that the quota has expired.
8	The PPS responds with an Access-Accept. If there are additional resources, the PPS allocates additional quotas and the service continues.

‌

Applying HTTP Redirection Rule when Quota is Reached

The following figure and table provide a high-level view of the steps showing how the HTTP Redirection Rule is applied once a quota is reached.

Call Flow for Applying HTTP Redirection Rule on Quota-Reach

Call Flow for Applying HTTP Redirection Rule on Quota-Reach

Step	Description
1	The Volume or Duration quota is reached. The Termination-Action is Request More Quota.
2	The PPC sends an Online Access Request to the AAA server and waits for Access-Accept.
3	The Access-Accept is received. It contains no additional quota attributes. The Termination-Action is Redirect/Filter. There is an HTTP Redirection Rule with redirect rule present in the Access-Accept.
4	The PPC (home agent) applies the HTTP Redirection Rule for the HTTP traffic. All other traffic is dropped. During this period, the MS recharges from the portal.
5	The PPC sends updated quota attributes to the AAA server based on the MS recharge from the portal.
6	The AAA server sends a CoA message to the PPC (home agent) with the new quota attributes in PPAQ and also sends the HTTP Redirection Rule to clear the HTTP Redirection rule at the PPC.
7	Normal traffic, including HTTP traffic, is allowed, per the new quota attributes.

‌

Applying HTTP Redirection Rule When CoA is Received

The following figure and table show the steps involved in applying the HTTP Redirection Rule when the PPAC receives a change of authorization (CoA) from a AAA server.

Call Flow for Applying HTTP-Redirection Rule when CoA is Received

Call Flow for Applying HTTP-Redirection Rule Received by CoA

Step	Description
1	The PPS updates the AAA server so that the AAA server dynamically enforces HTTP Redirection Rule at the PPC.
2	The AAA server sends a CoA message to the PPC (home agent) with the HTTP Redirection Rule.
3	The PPC (home agent) applies the HTTP Redirection Rule for the HTTP traffic. All other traffic is dropped. During this period, the MS is recharged from the portal.
4	The PPC sends updated quota attributes to the AAA server based on the MS recharge from the portal.
5	The AAA server sends a CoA message to the PPC (home agent) with the new quota attributes in PPAQ and also sends the HTTP Redirection Rule to clear the HTTP Redirection rule at the PPC.
6	Normal traffic, including HTTP traffic, is allowed, per the new quota attributes.

‌

Terminating the Call when Quota is Reached

The following figure and table provide a high-level view of the steps involved in allocating additional quotas for prepaid calls once the original quota is reached.

Call Flow for Terminating the Call on Quota-Reach

Call Flow for Terminating the Call on Quota-Reach

Step	Description
1	Volume or Duration quota is reached. If the termination-action is Request-More-Quota, step 2 occurs next. If termination-action is Terminate, step 4 occurs next.
2	If the termination-action is Request-More-Quota, the PPC sends an Online-Access-Request to the AAA server and waits for Access-Accept.
3	The PPC receives the Access-Accept, which contains no additional quota attributes.
4	Session is terminated at the PPC (home agent) and at the ASN GW.
5	The PPC sends the final Online-Access-Request.

‌

DHCP Relay Support for ASNGW

Following is a description of DHCP functionality to support ASNGW service. The functionality assumes the AAA to be RADIUS. To support Diameter AAA, the Access-Accept messages are correlated to DEA messages of the Diameter Protocol.

DHCP Keys

DHCP messages between the DHCP relay and DHCP server are authenticated by the DHCP Authentication Suboption. This requires that the DHCP relay and the DHCP server have a shared secret we call the DHCP-key.

The DHCP-key is specific between each DHCP Relay and DHCP server. The DHCP keys are derived from the DHCP-RK. The DHCP-RK key generation is internal to the AAA server and is transported as necessary to the authenticator and DHCP server using AAA protocol. The DHCP Key is derived from the DHCP-RK at the authenticator and at the DHCP server.

DHCP-RK and derived keys are not bound to individual user or authentication sessions, but to a specific DHCP server and DHCP relay/DHCP server) pairs. DHCP-RK is generated only on demand, but not for each EAP (re-)authentication taking place. Nevertheless, a DHCP-RK key along with the key identifier and lifetime values, are delivered to the authenticator during network access authentication of a MS (that is, it is carried by but otherwise unrelated to this specific MS). The lifetime and key identifier of DHCP-RK is managed by the AAA server. It is the responsibility of the AAA server to deliver a new DHCP-RK to the authenticator and DHCP server prior to the expiration of the DHCP-RK.

Key Generation

The DHCP-RK is created by the AAA server assigning the DHCP server to an authenticating subscriber. A different 160-bit random DHCP-RK is generated for every DHCP server.

From the DHCP-RK an authenticator generates DHCP-key for a specific DHCP relay/ DHCP server pair if requested by this DHCP relay. The DHCP-key is also generated by the DHCP server when a DHCP message arrives from a DHCP relay for which the DHCP server has no key yet.

From the DHCP-RK an authenticator generates a DHCP-key for a specific DHCP relay/ DHCP server pair if requested by this DHCP relay. The DHCP-key is also generated by the DHCP server when a DHCP message arrives from a DHCP relay for which the DHCP server has no key yet.

Key Distribution

The DHCP-RK keys are generated by the AAA server and are transported to the DHCP server and the Authenticator with the AAA protocol. The DHCP key generated by the authenticator is transported to the DHCP relay via WiMAX specific R4 signaling (Context Req/Rsp msg). The DHCP keys generated by the DHCP server are never transported outside of the DHCP server.

•	DHCP-RK Key: Generated by AAA, transported to authenticator and DHCP server through AAA protocol.

•	DHCP Key: Generated by authenticator and DHCP server, transported to DHCP relay and DHCP server via WiMAX-specific R4 signaling. Never transported outside of the DHCP server.

DHCP key distribution covers two scenarios. In the first scenario the authenticator and DHCP relay are co-located in the same entity. In the second scenario, no re-authentication takes place when the MS moves to a different anchor ASN hosting a new DHCP relay, so the anchor authenticator is continued to be used, and provisions the new DHCP relay with the required keys.

DHCP Relay in ASNGW for PMIPv4 Calls

The following steps are based on R3 already being secured. If R3 is not secured, the DHCP relay adds the authentication sub-option (as explained in step 12 ) to have data integrity and replay protection for relayed DHCP messages.

1.	The MS sends a DHCP Discover as a broadcast message. The DHCP message is sent on the MS's Initial service flow setup over R1 interface to the BS.

2.	The DHCP Discover message is forwarded from the BS to the DHCP Relay present in the ASN through the data path established for the ISF (Initial Service Flow) traffic.

3.

The DHCP Relay in ASN intercepts and changes the destination IP address from broadcast to unicast and configures the giaddr field in the DHCP payload. It then sends the DHCP Discover message to the DHCP server of the MS based on configuration information. The configuration information in the most generic case is downloaded via the AAA but it may also be statically provisioned. If the Datapath is per MS or SF, the MS context is found based on the Datapath and not on the MAC address. If the Datapath is per BS the MS context is found based on the MAC address or MS NAI

4.	DHCP servers receiving the DHCP Discover request reply by sending a DHCP Offer message including an offered IP address.

5.

The DHCP Relay in the ASN forwards the DHCP replies to the MS. The DHCP Offer message is sent from ASN GW to BS through the Data Path. The destination IP address of the DHCP Offer message sent to MS is a unicast one. Normally DHCP servers or relay agents attempt to deliver the DHCP Offer to a MS directly using unicast delivery. However, some MS implementations are unable to receive such unicast IP datagram until they know their own IP addresses. To work around this, an MS's broadcast address may be used in the DHCP Offer message. The ASN checks the BROADCAST (B) flag in the DHCP Offer message. If this flag is set, the ASN uses a broadcast address to send DHCP Offer message. Otherwise the unicast address is sent, but the delivery is over a unicast CID

6.	BS sends DHCP Offer message to the MS on the MS's Initial Service Flow.

7.	The MS receives a DHCP Offer message and sends a DHCP Request to the selected DHCP server as a broadcast message confirming its choice of the DHCP Server.

8.	DHCP Request message is sent from BS to DHCP relay in ASN through the established Data Path.

9.

The DHCP Relay in the ASN prompts the PMIP client to initiate the Mobile IP Registration procedure. The PMIP client uses the HoA information to construct a Mobile IP Registration Request message. This message contains HoA and CoA for this MS. The source address for this R3 message is CoA, and the destination address is HA address.

10.	The HA responds with the Mobile IP Registration Response message in which the source address for this R3 message is the HA address, and the destination address is CoA.

11.	After the establishment of the MIP tunnel the PMIP client informs the DHCP Relay with the MIP registration result. The DHCP Relay in ASN relays the DHCP Request with the optional MIP registration result encapsulated in the WiMAX vendor specific relay agent suboption to the DHCP server.

12.	The selected DHCP server receives the DHCP Request and replies with a DHCP Ack containing the configuration information requested by the MS.

13.	The DHCP Relay relays the DHCP Ack to the BS.

14.

BS sends DHCP Ack message to the MS on the MS's provisioned Initial Service Flow.If MS doesn't receive a DHCP Ack, or DHCP NAK message when timeout, it retransmits the DHCP Request. If neither DHCP Ack nor DHCP NAK is received when the maximum retransmission reached, MS restarst the IP initialization process.

DHCP Relay Requirements for Simple IP Calls

The DHCP relay handles all DHCP messages sent by the MS to the broadcast IP address.

•	The DHCP relay is configured with the DHCP server address during the MS authentication. The AAA server sends the address of the DHCP server in the AccessAccept message. The DHCP relay uses this address to relay the DHCP messages from the MS to the DHCP server.

•

Upon receiving a DHCP DISCOVER message from the MS, the DHCP relay verifies the "chaddr" field in the DHCP header and matches the MS MAC address associated with the R6/R4 over which the DHCP message is received. This is feasible without any additional option in the DHCP message since the DHCP relay is collocated with the Anchor ASN (ASN-GW for profiles A and C). This is done to prevent MAC address spoofing by a rogue MS.

•

If the DHCP relay determines that the MS has included a MAC address in the chaddr field of the DHCP DISCOVER message that does not match the known MAC address of the R6/R4 over which the DHCP message was received, the DHCP relay consider the following action: A rogue MS is trying to spoof MAC address. In this case, the DHCP relay informs the DPF to initiate R6 teardown.

•

After determining the NAI to be used for the request, the DHCP relay adds the relay agent option to the original DHCP message and sets the Subscriber-ID suboption to the NAI used for MIP associated with MS. If there is a secure communication channel between the DHCP relay and the DHCP server, the relay and server may choose to omit the authentication suboption.

•	If a DHCP Decline message is received, the DHCP Relay forwards the message to the DHCP Server. The messaging between the DHCP relay and DHCP server is transported over the R3 interface.

•	When DHCP relay receives the DHCP OFFER message from the DHCP server, it relays it to the MS. If the DHCP server included the authentication suboption is in the relay agent option, the DHCP relay validates it before relaying the DHCP OFFER to the MS.

•	The DHCP relay behavior for handling DHCPREQUEST or DHCPDECLINE from the MS is same as in the case of DHCP DISCOVER.

•	The DHCP relay intercepts the DHCP renewal and release messages, and verifies the content of the message. If R3 is not secured (e.g., by IPSec), the DHCP relay adds the relay agent authentication suboption to the message before relaying it to the DHCP server.

DHCP Relay Requirements for PMIPv4 Calls

The DHCP relay handles all DHCP messages sent by the MS to the broadcast IP address. The DHCP relay is configured with the DHCP server address during the MS authentication. The AAA server sends the address of the DHCP server in the RADIUS AccessAccept message or Diameter WDEA command. The DHCP relay uses this address to relay the DHCP messages from the MS to the DHCP server.

•

Upon receiving a DHCP DISCOVER message from the MS, the DHCP relay verifies the chaddr field in the DHCP header matches the MS MAC address associated with the R6/R4 over which the DHCP message is received. This is feasible without any additional option in the DHCP message since the DHCP relay is collocated with the Anchor ASN (ASN-GW for profiles A and C). This is done to prevent MAC address spoofing by a rogue MS.

•

If the DHCP relay determines that the MS has included a MAC address in the chaddr field of the DHCP DISCOVER message does not match with the known MAC address associated with the R6/R4 over which the DHCP message was received, the DHCP relay considers that a rogue MS is trying to spoof the MAC address. In this case, the DHCP relay may inform the DPF to initiate R6 teardown.

•

After determining the NAI to be used for the request, the DHCP relay adds the relay agent option to the original DHCP message and sets the Subscriber-ID suboption to the NAI used for MIP associated with MS. If there is a secure communication channel between the DHCP relay and the DHCP server, the relay and server may choose to omit the authentication suboption. T

•	If a DHCP Decline message is received, the DHCP Relay forwards the message sto the DHCP Server.

•	When DHCP relay receives the DHCP OFFER message from the DHCP server, it relays it to the MS. If the DHCP server included the authentication suboption in the relay agent option, the DHCP relay validates it before relaying the DHCP OFFER to the MS.

•	The DHCP relay behavior for handling DHCP REQUEST or DHCP DECLINE from the MS is same as in the case of DHCP DISCOVER

•

When DHCP relay receives the DHCP REQUEST message from the MS, it prompts the PMIP4 client to initiate MIPv4 registration procedures. It passes the requested IPv4 address and the HA information to the PMIP4 client. The PMIP4 client performs the registration with the FA and HA on behalf of the MS. The PMIP4 client informs the DHCP relay with the MIPv4 registration result.

•

Upon receipt of such indication, the DHCP relay relays the DHCP REQUEST message with the MIP registration result encapsulated in the vendor specific relay agent suboption code 1 to the DHCP Server. If this suboption is not sent to the DHCP server and the MIP registration indicates a failure, the DHCP relay does not forward the DHCP REQUEST message to the DHCP server and the network performs an exit for the corresponding MS. When the DHCP relay receives the DHCPACK message from the DHCP Server, it relays the DHCPACK message to the MS.

•

Since AAA can assign different HAs (e.g., when dynamically assigning HA from a pool) and each HA handles different MS subnets, the assigned HA needs to be passed to DHCP server to allow choosing the matching MS address pool. DHCPDISCOVER and DHCPREQUEST from MS SHOULD include HA IP address in same vendor specific relay agent suboption code 2 to the DHCP Server

RADIUS Based Procedures for Prepaid Accounting

In prepaid accounting, the ASNGW works as the prepaid client (PPC). When there is a mobile IP call, both the ASNGW and HA can work as the PPC independently. However, either the HA or ASNGW, not both, is responsible for prepaid accounting. In the case of Simple IP calls, the ASNGW can act as the prepaid client for prepaid subscriber calls.

Online accounting is set up by the exchange of RADIUS Access-Request and Access-Accept packets. The initial Access-Request packet from the ASNGW and or the HA includes a prepaid accounting capability (PPAC) VSA to the PPS indicating support for On-line accounting at the ASN and or the HA.

If the subscription session requires online charging, in the case of session-based prepaid accounting, the AAA server (or PPS) assigns a prepaid accounting quota (PPAQ) to the PPC (HA or ASNGW) by encoding the PPAQ values in the RADIUS Access-Accept packets. As the session continues, the PPC and the PPS replenish the quotas by exchanging RADIUS packets. In the case of IP 5-tuple flow-based prepaid accounting, when traffic is received for a configured prepaid IP flow, the PPAC sends an authorize-only access-request to the AAA server to request and receive quota attributes for that flow.

In the case of session-based prepaid accounting, quotas are allocated to each session. The Service-ID in the PPAQ is sent to the IP-Address corresponding to the IP-Session.

Flow- based Prepaid Accounting

As per NWG WiMAX architecture, flow-based prepaid accounting can be either IP 5-tuple flow-based, PDF ID based. or SDF ID based. Currently, only the IP 5-tuple flow-based prepaid accounting is supported.

The ASNGW receives PPAQ attributes separately for each flow that requires flow-based accounting. The ASNGW performs pre-paid accounting for each of the flows for which prepaid accounting is configured. However, there can be flows for which pre-paid accounting is not requested. For those flows, session-based off-line accounting procedures are applied.

PPAQ attribute contains the Rating-Group-ID attribute which corresponds to one or more IP 5-tuple flows, depending on the configuration. The Rating-Group-ID identifies the flow for which pre-paid accounting is applicable. The format of Service-ID for flow-based accounting is as follows:

•

When the first data packet which belongs to a Rating-Group-ID for which prepaid is configured is received, the PPC (ASNGW or HA) requests quota attributes for this Rating-Group-ID. The PPC sends an Authorize-Only access-request and encoding PPAQ with Rating-Group-ID in it. The AAA server sends back the available/allocated quota attributes in an Access-Accept by encoding the PPAQ with the same Rating-Group-ID along with quota parameters.

•	In the case of IP 5-tuple flow-based prepaid accounting, the quota is requested based on Rating-Group-ID only. Configuration is required to map IP flows to Rating-Group-IDs.

•	On quota expiry for a Rating-Group-ID, the PPC (ASNGW/HA) sends an on-line access request to renew the quota. The ASNGW/HA includes the PPAQ for the corresponding Rating-Group-ID only in the on-line access request.

•

In the case of quota expiry for a flow, the ASNGW/HA renews the quota for that particular Rating-Group-ID. If there is no quota allocated for the rating-group, the traffic for that rating-group is dropped for some period (based on configuration). If there is any more traffic matching that rating-group after that period (based on configuration), the quota is requested again for that rating group.

Configuring Rating-Group-ID

IP 5-tuples are configured by using current active charging service ruledef configurations. Each ruledef is associated with a rating group ID by configuration. Several ruledefs (i.e., several IP 5-tuple rules) may be mapped to a single rating-group ID. Prepaid quota attributes are requested only on a ratinggroup ID basis.

Prepaid Tariff Switching

Prepaid Tariff Switching will be supported for IP 5-.tuple flow-based prepaid accounting.

Hotlining with Flow-based Prepaid Accounting

Hotlining is applied on a session basis. That is, when hotling has to be applied because of either quota expiry for a rating-group or because a CoA is received with hotlining parameters for a session, the entire session is hotlined even though there may be some rating-groups with quota remaining.

RADIUS-based Procedures for WiMAX Hotlining

The hotlining feature provides a WiMAX operator with the capability to address issues with users that would otherwise be unauthorized to access packet data services. The hotlining device (HLD) can be located at the ASN or CSN.

Types of Hotlining

There are two methods defined by which the HAAA indicates that a user is to be hot-lined:

•	Profile based hotlining: Hot-line profile(s) with all hotlining rules are pre-provisioned at the HAAA. The HAAA sends a hot-line profile identifier in the RADIUS message (Access-Accept and Change of Authorization) when the hotlining is activated.

•

Rule based hotlining: Hotlining rules (filter rules, IP or HTTP redirection rules) are sent in the RADIUS message (Access-Accept and Change of Authorization) by the HAAA when the hotlining is activated. Cisco Systems supports profile based hotlining and rule-based hotlining with HTTP redirection rules only. Rule-based hotlining with IP-Redirection-Rules and NAS-Filter-Rules are currently not supported.

Based on the status of the user's session, there are two ways users can be hot-lined:

•	Active session hotlining: The user starts a normal packet data session. At some point in the session, the HAAA receives a trigger for hotlining from the hotlining application (HLA).

•	New session hotlining: The trigger from the HLA arrives prior to the user access authentication.

Once the hotlining is resolved, the packet data session returns to normal. Both these approaches are discussed in the following sub-sections.

Hotlining for Prepaid Accounting Sessions

In the case of mid-session hotlining, if an access-request is sent by the system to replenish the quota, the server may not have enough quota to allocate for the session. The AAA server may send hotlining attributes (profile-id or hotlining rules) and the termination-action in the PPAQ set to "Redirect/Filter" in the access-accept. In this case, the HA or ASNWG installs the hotlining rules when the quota is exhausted and the session becomes a hotlined session. If a CoA is received with hotline attributes, the hotlining rules are installed and the session becomes a hotlined session.

In the case of hotlining during initial session establishment, the AAA server may send hotlining attributes and 0 quota in the PPAQ. The termination-action in the PPAQ is set to "Redirect/Filter". In this case, the session would start as a hotlined session and the hotline rules are nstalled.

Hotline rules are either derived from the hotline rule attributes in access-accept in the case of rule based hotlining, or from the locally configured hotline profile-id (Filter/Redirection rules which are configured under the locally configured active-charging rulebase). The hotline profile-id is received from the AAA server in access-accept or in a CoA

Active Session Hot-lining Call Flows

The active IP session hot-lining is invoked when the user is currently engaged in a packet data session and the HAAA receives hot lining trigger from the HLA. Below figure depicts the call flow between the HLD, HAAA and HLA.

1.	User is in an active IP session which is not hotlined.

2.	The HLA detects that the user needs to be hot-lined. This is indicated to the HAAA by sending a Hotlining Active Trigger.

3.

When the home AAA server receives notification from the hotline applicaiton, it records the hotlining state against the user record in the database. The home AAA server determines whether the user has an ongoing packet data session. If the user has an ongoing packet data session, the home AAA server initiates the Active-Session Hotlining procedure. The home AAA server uses the contents of the Hotline Capability VSA and other local policies to determine which access device will be the Hotlining Device for the session. The home AAA server sends a RADIUS CoA-Request to the HLD with either Profile based hotlining or Rule based hotlining

4.

Upon receipt of the RADIUS COA, if the HLD can honor the request, it responds with a RADIUS COA Ack to the HAAA. If the HLD cannot honor the request, it responds with a COA NAK message. Based on the local policy, HAAA may either retry sending the hotlining request to the HLD or it may send a RADIUS Disconnect Message (DM) to the HLD to terminate the session. ASNGW/HA always sends COA ACK if the session is present.

5.	The HLD sends a RADIUS Accounting Request (Stop) indication for the active data session, with Session Continue set to true.

6.

The HLD sends a RADIUS Accounting Request (Start) for the hotlined session with Beginning of Session set to False. If the Session-Timeout attribute was included in step 3, the HLD initiates session teardown (i.e., tear down of the service flows associated with the IP session) when the duration specified in the Session-Timeout attribute has elapsed and the user's session is still hotlined. After tearing down the service flow(s), the HLD sends an Accounting Request (Stop) to the HAAA to inform that the user's IP session has ended. If the Session-Timeout times out while a session is hot-lined, the session is terminated.

7.

Since the user's data session is hot-lined in mid session, the user's data traffic is affected. Based on the hotlining rules set at the HAAA and indicated by it in the RADIUS COA earlier, the uplink and/or downlink data traffic of the user is either dropped, disconnected, or blocked, and redirected to the HLA by the HLD.

8.

Once the hotline status is applied to the user status, the HLA notifies the user of his/her hotlined status and resolves the issue. If the condition that triggered the hot-lining session is not cleared, the HLA may terminate the session. In this case, the HAAA is notified by the HLA. Upon receipt of this notification, the HAAA sends a RADIUS Disconnect Message to the HLD. The accounting records are stopped and session termination is initiated. This may happen automatically at the HLD if the user's hotlined status does not change during the Session-Timeout value. If the condition that triggered the hotlining session is cleared, the HLA sends the Hotlinig Inactive Trigger to the HAAA to clear the hotlined status of the user.

9.	Upon receipt of the Hotlining Inactive Trigger, the HAAA sends a RADIUS COA message to the HLD with appropriate attributes. Note that this may not be the same HLD that initially handled the activation of the hotlining. This may occur due to events such as handoff.

10.

Upon receipt of the RADIUS COA, if the HLD can honor the request it will respond with a RADIUS COA Ack to the HAAA. At that point the Hotline Session-Timeout timer is turned off. If the HLD cannot honor the request, it responds with a COA NAK message. Based on the local policy, the HAAA may retry sending the hotlining signal to the HLD or it may send a RADIUS Disconnect Message to the HLD to terminate the session. In this case, the HLD sends a RADIUS Accounting Request (Stop) message to the HAAA to indicate the end of the IP session for the user. This occurs after the Disconnect Message is processed and the service flow(s) associated with the IP session are torn down.

11.	The HLD generates a RADIUS Accounting Request (Stop) with Session Continue set to True message for the hotlined packet data session.

12.	The RADIUS Accounting Request (Stop) message with Session Continue set to True is followed by a RADIUS Accounting Request (Start) message with Beginning of Session set to False. This indicates the start of the normal packet data session.

13.	The user continues the packet data session and the traffic is routed normally. During the hotlined active status in the HLD, the byte, packet, and duration counts for user's hotlined IP session is counted towards the overall byte and packet counts.

Active Session Hotlining for Prepaid Users

Active IP session hotlining is invoked when the prepaid user is engaged in a packet data session and the HAAA /PPS does not grant additional quota to the user. The figure below shows the call flow between HLD/PPC, HAAA/PPS and HLA.

1.	The prepaid user is in an active IP session that is not hotlined.

2.	The threshold for the prepaid quota(s) is reached.

3.	PPC requests additional quota by sending an Authorize-Only Access-Request to the PPS containing one or more PPAQ(s) indicating which quota(s) need to be replenished.

4.	PPS responds with an Access-Accept packet. The balance on the user account is too low for additional quota to be allocated. Hotlining is triggered for the user to replenish his/her account. Access-Accept is sent to the HLD with either Profile-based Hot-lining or Rule-based Hot-lining.

5.	From this point on all steps are identical to “Active Session Hotlining for Prepaid Users.”

Hotlining During Initial Network Entry

During initial network entry, hotlining is invoked. (Triggers for invoking hotlining are not within the scope of this section.) Examples include limited access to emergency services, empty prepaid accounts, or mobility restriction applied to a fixed or nomadic subscription. This occurs when H-AAA detects that initial network entry is being performed at a BS that does not belong to the network entry zone of the MS. I

1.	The MS performs EAP authentication of initial network entry.

2.	The Authenticator sends Access-Request as part of the authentication procedure. The H-AAA server acquires the ASN hot-lining capabilities.

3.

If H-AAA activates hotlining, it sends an Access-Accept to the Authenticator/HLD with the appropriate attributes. The H-AAA may activate hotlining, depending on application-specific conditions such as emergency network entry (indicated by ES specific NAI), mobility restrictions applying to fixed or nomadic subscribers, or an empty prepaid account.

4.	The anchor SFA located with the authenticator establishes the initial service flow (ISF) for the MS.

5.	The MS gets an IP address from network side if an IP address is required for hotlining.

6.	The authenticator/HLD sends a RADIUS Accounting Request (Start) for the hotlined session to indicate the activation of hot-lining.

7.	Based on the hotlining rules received from the H-AAA server, the uplink and/or downlink data traffic of the user is either dropped or blocked, and redirected to the HLA by the HLD.

8.	If the HAAA detects that the condition that triggered the hot-lining of the session is cleared, the HAAA sends a Radius COA message to the Authenticator/HLD with the appropriate attributes.

9.	Upon receipt of the Radius COA, the authenticator/HLD responds with a Radius COA Ack to the HAAA.

10.	The authenticator/HLD sends a Radius Accounting Request (Stop) to the HAAA to indicate the inactivation of the Hotlining.

Tariff Switching for Prepaid Accounting

The PPC and the PPS may support the tariff switching mechanism described in this section. This mechanism is useful if, for example, traffic before 18:00 is rated at rate r1 and traffic after 18:00 is rated at rate r2. The mechanism requires the PPC to report usage before and after the switch occurrs.

The PPC indicates support for tariff switching by setting the appropriate bit in the PPAC. If the PPS needs to signal a tariff switch time, it sends a PTS attribute that indicates the point in time when the switch will occur. This indication represents the number of seconds from current time (TariffSwitchInterval TSI).

At some point after the tariff switch, the PPC sends another Access-Request, as a result of the user having logged off or the volume threshold being reached. The PPC reports how much volume was used in total (in a PPAQ attribute) and how much volume was used after the tariff switch (in a PTS VUATS subtype attribute). In situations with multiple tariff switches, the PPS must specify the length of the tariff switch period using the TimeIntervalAfterTariffSwitchUpdate (TITSU) in the PTS attribute.

When a TITSU is specified in the PTS, the PPC generates an Access-Request within the time after TSI and before TITSU expires. Note that, typically, the PPC is triggered by the Volume Threshold. However, it is possible that during period r2, resources may not be entirely consumed and the threshold not reached. The TITSU attribute ensures that, even in this case, the PPC will generate the new Access-Request in good time.

Note that it is not efficient to use the tariff switching mechanism for services that are metered based on time and uninterrupted consumption. Also note that separate services flows may have individual tariff periods.

CSN Procedure Flows

This section provides an overview of CSN procedure and working of ASN Gateway in CSN procedure.

PMIP4 Connection Setup and Call Flow with DHCP Proxy

This section describes the CSN procedure of simple IP with DHCP proxy triggering PMIPv4 for a WiMAX subscriber.

The following figure and table provide a high-level view of the steps involved in PMIP4 connection and call flow of an SS/MS.

PMIP4 Connection Setup Call Flow

PMIP4 Connection Setup Call Flow Description

Step	Description
1	Initial network entry completed as described in ASN Procedures.
2	MS sends DHCP DISCOVER message to DHCP Proxy (co-located with ASN Gateway) to discover a DHCP server for IP host configuration.
3	Upon receiving the DHCP DISCOVER message, the DHCP Proxy in the NAS triggers the PMIP4 client to initiate 8 the Mobile IPv4 Registration procedure.The PMIP4 client uses the HoA information and constructs a Mobile IPv4 Registration Request message and sends the Mobile IPv4 Registration Request to the FA address. The FA forwards the registration request to the CSN HA.
4	CSN HA processes the MIPv4 Registration Request.If a HoA is 0.0.0.0 in the Mobile IP Registration Request message, the HA assigns a HoA. Otherwise, the HoA in the Mobile IP Registration Request message is used.
5	The HA responds with the Mobile IP Registration Response message.The source address for this Mobile IPv4 message over R3 is HA, and the destination address is FA-CoA.The FA forwards the message to the PMIP4 client. The PMIP4 client passes this information to the DHCP proxy.
6	The DHCP proxy sends the DHCP OFFER message to the MS.
7	MS sends a DHCP REQUEST to the DHCP Proxy with the information received in the DHCP OFFER.
8	The DHCP Proxy acknowledges the use of this IP address and other configuration parameters by sending the DHCP ACK message.
9	WiMAX session established between MS and CSN HA.

‌

PMIP4 Session Release

This section describes the CSN procedure of PMIPv4 session release during a WiMAX subscriber session.

The following figure and table provide a high-level view of the steps involved in PMIPv4 session release and termination of connection an SS/MS.

PMIP4 Session Release Call Flow

PMIP4 Session Release Call Flow Description

Step	Description
1	The session release trigger send by MS sending DHCP-Release message to the ASN GS or DHCP proxy has expired on lease time or FA initiates session release.
2	ASN Gateway initiates the session release with PMIPv4 client by sending FA_Revoke_Req and sends PMIP De-Reg RRQ (Registration Revocation) message to CSN HA.
3	CSN HA starts release of MIP binding.
4	CSN HA sends PMIP De-Reg RRQ (Registration Revocation) message to ASN Gateway and PMIP client sends GA_Revoke_Rsp message to ASN Gateway.
9	WiMAX session terminated between MS and CSN HA.

‌

WiMAX Deployment with Legacy Core Networks

ASN Gateway can inter-operate with a 3GPP overlay and 3GPP2 overlay and provide continuity support for 3GPP2 and WiMAX handovers.

ASN Gateway Interoperability with 3GPP Overlay

The following figure shows a typical interoperability scenario between WiMAX and 3GPP legacy networks with reference points and interfaces.

ASN Gateway with 3GPP Overlay

ASN Gateway Interoperability with 3GPP2 Overlay

The following figure shows a typical interoperability scenario between WiMAX and 3GPP2 legacy networks with reference points and interfaces.

ASN Gateway with 3GPP2 Overlay

Session Continuity Support for 3GPP2 and WiMAX Handovers

This feature provides seamless 3GPP2 session mobility for WiMAX subscribers and other access technology subscribers. With the implementation of this feature, the HA can be configured for:

•	3GPP2 HA service

•	3GPP HA service

•	WiMAX HA service

•	A combination of 3GPP2 and WiMAX HA services

The above configurations provide the session continuity capability that enables a dual-mode device (a multi-radio device) to continue its active data session as it changes its active network attachment from 3GPP2 to Wimax and vice versa, with no perceived impact from a user perspective. This capability brings the following benefits:

•	Common billing and customer care

•	Accessing home 3GPP2 service through Wimax network and vice versa

•	Better user experience with seamless session continuity

For more information on this support, refer to the HA Administration Guide.

NSP-ID and NAP-ID Functionality

NSP-ID and NAP-ID functionality enable the MS to discover all accessible network service providers (NSPs) in a WiMAX coverage area, and to indicate the NSP selection during connectivity to the ASN. The actual NSP selection by the MS may be based on various preference criteria, depending on the configuration information.

Configuration information includes:

•	Information useful in the MS discovery of the network access provider (NAP), including channel center frequency and PHY profile,

•	Information useful in the MS decision mechanism to prioritize NSPs for automatic service selection, including a list of authorized NAPs and NSPs,

•	A list of authorized share or roaming relationships between authorized NAPs and NSPs and partner NAPs and NSPs,

•	Identity credentials provided by the NSPs to which the MS has a business relationship, and

•	The mapping relation table between 24-bit NSP identities and corresponding realms of the NSPs.

Configuration information may be provided on a pre-provisioned basis or at the time of MS dynamic service subscription.

Manual Mode

The NSP Enumeration List is presented to the user for selection. Each entry presents only the verbose NSP name to the user. If more than one NAP can be used to establish a direct connection with a NSP, the MS may indicate each of the candidate NAPs along with the NSP or verbose NSP name to the user in the following order:

•

Home NSP.

•	If the “User Controlled RAPL” (Roaming Contractual Agreements Preference List) is available, NSPs or their corresponding verbose NSP names in the “User Controlled RAPL” in the MS (in priority order),

•	If the “Operator Controlled RAPL” is available, NSPs or their corresponding verbose NSP names in the “Operator Controlled RAPL” in the MS (in priority order),

•	Any other NSP or their corresponding verbose NSP names in random order.

Upon selection and successful authentication to the selected NSP, the MS indicates the selected NSP. If no NSP is found, the MS behavior is implementation dependent.

Automatic Mode

For Automatic Mode, without user intervention, the MS selects a NAP that has a direct connection to the home NSP. If more than one NAP can be used to establish a direct connection with an NSP, the MS selects a NAP by using “User Controlled CAPL” (Contractual Agreements Preference List) or “Operator Controlled CAPL”.

If a NAP that has direct connection to the home NSP is not found, the MS attempts to select a NAP that has connection to one of the NSPs in the Preferred NSPs list. The order that the MS follows for selection from the NSP Enumeration List is determined by the “User Controlled CAPL” and “Operator Controlled CAPL”, if available in the configuration information.The MS selects and tries to authenticate with an available and allowable NSP, in the following precedence:

•

Home NSP,

•	If the “User Controlled RAPL” is available, NSPs in the “User Controlled RAPL” in the MS (in priority order),

•	If the “Operator Controlled RAPL” is available, NSPs in the “Operator Controlled RAPL” in the MS (in priority order),

•	Any other NSP in random order.

Upon selection and successful authentication to the selected NSP, the MS indicates the selected NSP. If no NSP is found, the MS behavior is implementation dependent.

ASN GW and NAP-ID/NSP-ID Process

Following is an overview of NAP-ID and NSP-ID process from the ASN GW’s perspective:

1.	NAP/NSP advertisement: BS advertises the available NAP/NSP to MS. The MS chooses one of the preferred NAP/NSPs and performs INE with that NAP/NSP. The BS/MS supports this function; the ASN GW does not play a role.

2.	Once the MS selects an NSP, the MS performs INE with the selected NSP to authenticate the MS at the selected NSP. The ASN GW enables the MS to get service from that NSP. In short, the ASN GW routes the Authentication request to the right AAA server, based on the NAI.

3.	The NSP-ID is included in the access request from the ASN GW.

4.	The ASN GW and HA sends the NSPID in authentication and accounting procedures to AAA server. The ASNGW does not send NAPID in authentication and accounting procedures to the AAA server, since the ASNGW sends the BSID to the AAA server.

Data Tunnel Endpoint Support

ASNGW supports forwarding downlink data to different endpoint tunnels other than the control address on the BS. In addition, the ASNGW can process uplink data and control traffic on different paths (VLANs) on the ASNGW if the data and control traffic are hosted on a different IP address.

The control and data tunnel endpoint can be different for the BS or the ASNGW. If the data tunnel endpoint is different from the control endpoint, it applies for both downlink and uplink traffic destined to, or received from, the peer (BS or ASNGW). This means that when downlink traffic is sent to the peer, the data tunnel endpoint is the destination IP address; when the uplink traffic is received from this peer, the source IP address is the data tunnel endpoint. The GRE key is unique for downlink and uplink data paths.

ASNGW with a Different Tunnel Endpoint

The ASNGW supports different data tunnel points on the BS for downlink traffic. The BS conveys its data tunnel endpoint through the existing R6 TLVs within MS Info.

If the uplink has a different data tunnel point, the ASNGW adds this information in the message that carries MS information, including the TLV or data path TLV that describes uplink service flow. There is a unique GRE key assigned to the uplink data path.

The ASNGW includes the tunnel endpoint TLV in the data path messages to BS or from the non-anchor GW to the anchor GW and vice-versa, to support the handoff functionality. After receiving the tunnel endpoint TLV within the data path messages, the BS forwards all the uplink data traffic to the same address.

No Handoff (INE)

For the control and data path setup for the INE, the BS/ASN specifies the different IP addresses for control and data traffic. For example, DT1 and BS1 are the data and control endpoints on the BS side. AT1 and AS1 are the data and control endpoints respectively on the ASNGW side. If the ASNGW requires different data tunnel endpoints instead of control addresses, the tunnel endpoint IP address has to be populated in the MS information TLV if it is per BS for DP Reg Request/Response message.

The ASNGW creates an NPU flow using the tunnel IP address if received in the DP Reg Response message for the uplink packet. From now on, all the data packets received from the BS have the source address of DT1. For all the downlink traffic, the ASNGW forms the data packet using the ASNGW Data IP address as the source address; the AS1 and destination address of the tunnel are the tunnel endpoint (that is, DT1). If no tunnel end point attribute is received from BS/ASNGW, by default, the control IP address is used for data traffic.

If the ASNGW requires a different data tunnel endpoint instead of a control address, the tunnel endpoint IP address is populated in the MS information TLV if it is per BS for DP Reg Request/Response message.

Inter-ASNGW Handoff

For control and data path setup for an inter-ASNGW handoff, the serving base station (SBS) is connected to the anchor GW and the target base station (TBS) is connected to the non-anchor GW. During INE, the anchor GW specifies a different IP address for data traffic. For example, if AT1 and DT1 are the data endpoints on the ASNGW and SBS side, the ASNGW informs the SBS about a different address for data by sending out a tunnel endpoint IP address in the MS information TLV in the DP-Reg Request during INE.

Similarly, during inter-ASNGW handoff, the non-anchor GW specifies the different data tunnel endpoint for uplink traffic in the DP-Reg Rsp message. The same address on the non-anchor GW receives the downlink data packets from the anchor GW. AT2 and DT2 are the data tunnel endpoint for the non-anchor GW and TBS, respectively. The tunnel endpoint IP address is populated in the MS information TLV in DP Reg Rsp message from non-anchor GW to the TBS.

Intra-ASNGW Handoff

For intra-ASNGW handoff, during INE, the ASNGW specifies the different data tunnel endpoint for receiving uplink traffic in the DP-Reg Req message to the serving base station (SBS). After handoff, the ASNGW specifies the different data tunnel endpoint to receive the Uplink traffic in the DP-Reg Rsp message. For example, AT1 is the tunnel endpoint on ASNGW for data traffic. DT1 and DT2 are the data tunnel endpoints on the SBS and TBS, respectively. The ASNGW provides the tunnel endpoint in the MS information TLV within the data path messages

AS1 is the control address on the ASNGW to negotiate R6 control traffic. SB1 and TB1 are the control addresses on SBS and TBS, respectively. The ANCHOR GW specifies the tunnel endpoint to receive the uplink traffic in the DP-Reg Rsp message. AT1 and AT2 are the data tunnel endpoints on the anchor and non-anchor GWs, respectively to negotiate R6 control traffic. SB1 and TB1 is the control address on SBS and TBS, respectively.

Supported Standards

WiMAX/IEEE References

•	“WiMAX ASN Profiles”, WiMAX Forum

•	“Initial Network Entry Stage 3”, Draft T33-001-R016v01-G Specification WiMAX Forum

•	“Procedures and Messages for ASN Anchored Mobility with Profile C: Stage 3” draft, WiMAX Forum

•	“Procedures for CSN Anchored Mobility Stage 3” draft, WiMAX Forum

•	“WiMAX End-to-End Network Systems Architecture: Stage 2 Draft Specification”, Release 1.0.0 Draft, March 28, 2007, WiMAX Forum

•	“WiMAX End-to-End Network Systems Architecture: Stage 3: Detailed Protocols and Procedures”, Release 1.0.0 Draft, March 28, 2007, WiMAX Forum

•	“WiMAX Forum Network Architecture - Stage 3-Detailed Protocols and Procedures” - DRAFT-T33-001-R015v01-J

IEEE Standards

•	IEEE 802.16e/D12 September 2005, Local and Metropolitan Area Networks – Part 16: Air Interface for Fixed Broadband Wireless Access Systems, Feb 2006.

•	802.1P QoS at MAC Level

•	802.1Q VLAN Standard

•	IEEE 802.16e/D12 September 2005, Local and Metropolitan Area Networks - Part 16: Air Interface for Fixed Broadband Wireless Access Systems, March 2004.

IETF References

•	RFC-1701, Generic Routing Encapsulation (GRE), October 1994

•	RFC-2131, Dynamic Host Configuration Protocol (DHCP), March 1997

•	RFC-2794, Mobile NAI Extension

•	RFC-2865, Remote Authentication Dial In User Service (RADIUS), June 2000

•	RFC-2866, RADIUS Accounting, June 2000

•	RFC-3012, Mobile Ipv4 Challenge/Response Extensions, November 2000

•	RFC-3024, Reverse Tunneling for Mobile IP, revised, January 2001

•	RFC-3046, DHCP Relay Agent Information Option, January 2001

•	RFC-3344, Mobile IP support for Ipv4, August 2002

•	RFC-3579, RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP), September 2003

•	RFC-3588, Diameter Base Protocol, September 2003

•	RFC-3748, Extensible Authentication Protocol, June 2004

•	RFC 1918, NWG, Stage 2 Architecture, 121505

•	RFC 3115, Mobile IP Vendor/Organization-specific Extensions

Object Management Group (OMG) Standards

•	CORBA 2.6 Specification 01-09-35, Object Management Group

 

 

Cisco Systems Inc.

Tel: 408-526-4000

Fax: 408-527-0883